netdev - RE: [PATCH] NET: Multiqueue network device support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Jun 2007 23:41:01 -0400
From:	"Leonid Grossman" <Leonid.Grossman@...erion.com>
To:	"Jason Lunz" <lunz@...ooley.org>,
	"David Miller" <davem@...emloft.net>
Cc:	<greearb@...delatech.com>, <jeff@...zik.org>,
	<netdev@...r.kernel.org>, <kaber@...sh.net>, <hadi@...erus.ca>,
	<peter.p.waskiewicz.jr@...el.com>, <auke-jan.h.kok@...el.com>
Subject: RE: [PATCH] NET: Multiqueue network device support.



> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Jason Lunz
> Sent: Tuesday, June 12, 2007 2:48 PM
> To: David Miller
> Cc: greearb@...delatech.com; jeff@...zik.org; netdev@...r.kernel.org;
> kaber@...sh.net; hadi@...erus.ca; peter.p.waskiewicz.jr@...el.com;
> auke-jan.h.kok@...el.com
> Subject: Re: [PATCH] NET: Multiqueue network device support.
> 
> On Tue, Jun 12, 2007 at 02:26:58PM -0700, David Miller wrote:
> > The MAC is still very much centralized in most designs.
> >
> > So one way they'll do it is to support assigning N MAC addresses,
> > and you configure the input filters of the chip to push packets
> > for each MAC to the proper receive queue.
> >
> > So the MAC will accept any of those in the N MAC addresses as
> > it's own, then you use the filtering facilities to steer
> > frames to the correct RX queue.
> >
> > The TX and RX queues can be so isolated as to be able to be exported
> > to virtualization nodes.  You can give them full access to the DMA
> > queues and assosciated mailboxes.  So instead of all of this bogus
> > virtualized device overhead, you just give the guest access to the
> > real device.
> >
> > So you can use multiple queues either for better single node SMP
> > performance, or better virtualization performance.
> 
> Are you aware of any hardware designs that allow other ways to map
> packets onto rx queues?  I can think of several scenarios where it
> could
> be advantageous to map packets by IP 3- or 5-tuple to get cpu locality
> all the way up the stack on a flow-by-flow basis. But doing this would
> require some way to request this mapping from the hardware.

10GbE Xframe NICs do that, as well as rx steering by MAC address, VLAN,
MS RSS, generic hashing and bunch of other criteria (there is actually a
decent chapter on rx steering in the ASIC manual at www.neterion.com
support page).
The caveat is that in the current products the tuple table is limited to
256 entries only. Next ASIC bumps this number to 64k.

> 
> In the extreme case it would be cool if it were possible to push a
> bpf-like classifier down into the hardware to allow arbitrary kinds of
> flow distribution.
> 
> Jason
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html