From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by huchra.bufferbloat.net (Postfix) with ESMTP id 5788C20024C for ; Tue, 13 Mar 2012 11:50:04 -0700 (PDT) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7202C7300B; Tue, 13 Mar 2012 20:08:38 +0100 (CET) Date: Tue, 13 Mar 2012 20:08:38 +0100 From: Luigi Rizzo To: Stephen Hemminger Message-ID: <20120313190838.GA78827@onelab2.iet.unipi.it> References: <5ce67de28ae4c472a088f0a37e643092@localhost> <20120313090357.2c9ac0db@nehalam.linuxnetplumber.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120313090357.2c9ac0db@nehalam.linuxnetplumber.net> User-Agent: Mutt/1.4.2.3i Cc: bloat Subject: Re: [Bloat] high speed networking from userspace X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:50:04 -0000 On Tue, Mar 13, 2012 at 09:03:57AM -0700, Stephen Hemminger wrote: > On Tue, 13 Mar 2012 13:28:52 +0100 > Hagen Paul Pfeifer wrote: > > > > > On Mon, 12 Mar 2012 17:09:44 -0700, Dave Taht wrote: > > > > > is the by the same guy that did QFQ, and the results are quite > > > impressive. He (today) announced support for this interface for Linux. > > > > > > shades of VJ's 'network channels'! > > > > "already" implemented: > > > > see > > > > o http://www.ioremap.net/node/12 > > o http://www.ioremap.net/taxonomy/term/6 > > > > and all netdev discussions several years ago. > > > > HGN > > User space networking works well for single application be it routing, > bridging, network trading, or single appliance. It doesn't work on a > multi-application environment (ie desktop). The gain is only because > the userspace code can choose to do less, but do it faster. So if you > want full stack, and firewall; don't bother. The firewall is actually one place where an efficient I/O mechanism is really useful. Netmap (or the netfilter API or netgraph in FreeBSD, if they were not built on top of skbufs/mbufs) give you an ideal place to efficiently drop rogue traffic, and reinject the interesting one in the stack for further processing. Also the concepts used in netmap (and in VJ's netchannel) are not confined to userspace networking. Even in the kernel one can and probably should: - get rid of skbufs/mbufs even in the kernel (replacing them with cheaper containers or data copies) - do more packet coalescing (software RSC is an example), to amortize certain costs over larger batches; - move work away from the interrupt/polling threads and closer to the user thread (for better cache locality and load management) The real gain of these mechanisms, i think, is having the option to avoid costly operations when you don't need them. That's the message i would like to convey. Of course everything would be more convincing if i came up with a full skbuf-less in-kernel stack and not just the bottom layer+libpcap :) cheers luigi