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]
Message-Id: <20070612.142658.45082832.davem@davemloft.net>
Date:	Tue, 12 Jun 2007 14:26:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	greearb@...delatech.com
Cc:	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.

From: Ben Greear <greearb@...delatech.com>
Date: Tue, 12 Jun 2007 14:17:44 -0700

> Jeff Garzik wrote:
> > 
> > If hardware w/ multiple queues will the capability for different MAC 
> > addresses, different RX filters, etc. does it make sense to add that 
> > below the net_device level?
> > 
> > We will have to add all the configuration machinery at the per-queue 
> > level that already exists at the per-netdev level.
> 
> Perhaps the mac-vlan patch would be a good fit.  Currently it is all
> software based, but if the hardware can filter on MAC, it can basically
> do mac-vlan acceleration.  The mac-vlan devices are just like 'real' ethernet
> devices, so they can be used with whatever schemes work with regular devices.

Interesting.

But to answer Jeff's question, that's not really the model being
used to implement multiple queues.

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.

-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ