From owner-freebsd-stable@FreeBSD.ORG Wed Nov 24 09:54:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CE37106566C for ; Wed, 24 Nov 2010 09:54:26 +0000 (UTC) (envelope-from greenx@yartv.ru) Received: from mail.yartv.ru (smtp.yartv.ru [94.158.0.17]) by mx1.freebsd.org (Postfix) with ESMTP id 22CB98FC0A for ; Wed, 24 Nov 2010 09:54:24 +0000 (UTC) Received: from greenx.yartelenet.ru (greenx.yartelenet.ru [94.158.0.2]) by mail.yartv.ru (Postfix) with ESMTP id A5363730F6 for ; Wed, 24 Nov 2010 12:36:09 +0300 (MSK) Message-ID: <4CECDC89.7070706@yartv.ru> Date: Wed, 24 Nov 2010 12:36:09 +0300 From: Andrey Groshev User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.15) Gecko/20101101 Thunderbird/3.0.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201010221416.o9MEGSa0094817@lava.sentex.ca> <201010221425.o9MEPcWC094867@lava.sentex.ca> <201010221848.o9MIm7WF096197@lava.sentex.ca> <4CC1F3B8.3010302@bogus.com> <4CC225D3.1030502@ops-netman.net> <7.1.0.9.0.20101022210145.06fe25e8@sentex.net> <201010230159.o9N1xGGF098363@lava.sentex.ca> <201010230821.o9N8LVuR001382@lava.sentex.ca> <20101023091555.W66242@maildrop.int.zabbadoz.net> <20101123175100.V24596@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: upd: 7.2->8.1 & many networks trouble & flowtable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 09:54:26 -0000 Hi, PPL! A couple of days ago decided to upgrade from 7.2-STABLE to 8.1-STABLE (amd64). By tradition, waited some pitfalls. But damn, not to the same degree! The hardware on the server: Motherboard: Intel SE7520JR23S CPU's: 2 x Xeon 3Ghz Ram: 4Gb Software used: openospfd, openbgpd, bind, and so on. In general, used as a boundary Router. Update ... and began: 1. The server died a few minutes after launch, not even reacting to the keyboard. By issuing a warning about "em0 watchdog .....". I thought to myself - broke the driver, connect the other network card. Server even stopped hanging. 2. Nearest switch does not like OSPF from the server and it shuts down a port or vlan. 3. openbgpd loads CPU nearly 100%. 4. bind does not respond, despite the fact that properly loads the CPU. In the end, I turned off everything that does not work as is necessary, Only remaining process FLOWCLEANER which can be CPU at 100%. Google started about this flowcleaner. And what happened? I found a report entitled "Optimizing the BSD Routing System for Parallel Processing"(1). Roughly speaking, flowtable - a new approach to routing. Dividing the levels 2 and 3 can achieve more parallelism. But in the end, due to this - to increase network performance. Ok, everything looks great! And now I ask: for whom all this? IMHO for example, ISP. Or, as stated in the above-mentioned report: > >> "The main goals for redesigning the kernel routing infrastructure was to reduce the scope of the customization necessary when deriving products from FreeBSD, and to offer a generic solution that could be an integral part of the kernel." <<< What ultimately relevant only to the equipment is used at the ISP. Since the average user with its tiny routing table - it is not necessary. But beyond the problems begin. How long have you seen the ISP without "fullview bpg"? But beyond the problems begin. Almost everywhere where it is mentioned a problem with FLOWCLEANER recommended for deletion from the kernel option FLOWTABLE. And one of the co-authors wrote in his blog(2): > >> "One oversight that come up shortly afterwards is that it adversely impacts performance for systems with many routing prefixes to a greater degree than I had expected." <<< How long have you seen the ISP without "fullview bpg"? It turns out that the technology is designed to increase network performance that most network generally kills, which implies that it is not suitable for use. And here it is not simply included in the source tree, and is enabled by default in the GENERIC kernel! And do not say that there was no PR - they are (3)! ---- Sorry so long sets out the main meaning of the message is this: Why in the kernel introduced new features, if it is good only on paper? May exclude this option from the GENERIC kernel? ---- Links: 1. - http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf 2. - http://daemonflux.blogspot.com/2010/01/updates.html 3. - http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_flowtable.html