[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1fxhm8xl1.fsf@fess.ebiederm.org>
Date: Mon, 09 Mar 2009 09:34:02 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Patrick McHardy <kaber@...sh.net>
Cc: Mark Smith
<nanog@...5b20a518b8f6864949bd940457dc124746ddc.nosense.org>,
greearb@...delatech.com, David Miller <davem@...emloft.net>,
netdev@...r.kernel.org, shemminger@...ux-foundation.org
Subject: Re: MACVLANs really best solution? How about a bridge with multiple bridge virtual interfaces?
Patrick McHardy <kaber@...sh.net> writes:
> Eric W. Biederman wrote:
>> There are two tricky parts.
>>
>> One problem is that macvlans and the primary hardware device share the
>> same transmit queue. So when I have a broadcast packet on the primary
>> devices queue I don't know if I have already sent it out to the
>> macvlan devices or not.
>
> So its about receiving packets on macvlan when transmitting on the
> real device? That sounds like a really hard problem that would probably
> indeed be better solved by a bridge.
Yes. My concern is that if we hook the real device we will
software broadcast packets twice.
Now that I think about it we could call ndo_start_xmit directly
from the macvlan code, and bypass whatever hook we use to
intercept packets going out the normal device it should not
be too difficult.
Operationally it would be very nice if arp worked between a macvlan
and the real device.
Eric
--
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