[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <467A91C7.6030307@trash.net>
Date: Thu, 21 Jun 2007 16:57:11 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Prafulla Deuskar <pdeuskar01@...il.com>
CC: Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
shemminger@...ux-foundation.org, netdev@...r.kernel.org
Subject: Re: [NET 00/02]: MACVLAN driver
Prafulla Deuskar wrote:
> On 6/19/07, Jeff Garzik <jeff@...zik.org> wrote:
>> David Miller wrote:
>> > This is actually a real issue for virtualization, and many
>> > if not all current generation ethernet chips support
>> > programming several unicast ethernet addresses in the MAC.
>> >
>> > Networking switches in domain0 on virtualization hosts use
>> > this feature to support seperate MACs per guest node,
>> > and if the chip doesn't support this the chip is put into
>> > promiscuous mode.
>> >
>> > We don't have any clean interfaces by which to do this MAC
>> > programming, and we do need something for it soon.
>>
>>
>> Yep, that's been on my long term wish list for a while, as well.
>>
>> Overall I would like to see a more flexible way of allowing the net
>> stack to learn each NIC's RX filter capabilities, and exploiting them.
>> Plenty of NICs, even 100Mbps ones, support RX filter management that
>> allows scanning for $hw_limit unicast addresses, before having to put
>> the hardware into promisc mode.
>>
>> Jeff
>
> So how do we manage mac address to RX queue association?
This is not about multiple RX queues but filtering multiple unicast
addresses without going to promiscous mode. The addresses are used
by something outside the driver, like macvlan.
-
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