[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1wsb2k5vg.fsf@fess.ebiederm.org>
Date: Fri, 06 Mar 2009 07:50:27 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Patrick McHardy <kaber@...sh.net>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] macvlan: Support creating macvlans from macvlans
Patrick McHardy <kaber@...sh.net> writes:
> Eric W. Biederman wrote:
>> Patrick McHardy <kaber@...sh.net> writes:
>>
>>>> Hmm. Actually that appears to be a macvlan bug. It looks like if I
>>>> change the macaddress on a macvlan we don't update the hash chains.
>>>> So unless we have the same low byte we will be on the wrong hash chain
>>>> and not receive the packets for the mac we specified. Ouch!
>>> The address can only be changed while the device is down and unhashed.
>>
>> Point. The dev_unicast/dev_unicast_delete in macvlan_set_mac_address
>> appears to be completely unnecessary then.
>
> I think thats correct.
Actually it is really weird. We can change the mac address while
the devices is running but the code is broken because it does
not update the hash table.
> Refusing duplicate MACs (on one underlying device) makes sense, the
> results are undefined currently.
Then I will do that just for consistency.
> About the filtering - I don't like
> the idea too much given that we already have multiple possiblities
> to do that.
Agreed, and even more I can think of some reasons why would not want
that. The observation I have is that if really want separation you
need separate vlans to the switch. As the similar hardware based
features also don't perform egress filtering.
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