From: ebiederm@xmission.com (Eric W. Biederman)
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH] macvlan: Support creating macvlans from macvlans
Date: Fri, 06 Mar 2009 07:50:27 -0800 [thread overview]
Message-ID: <m1wsb2k5vg.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <49B14234.5030206@trash.net> (Patrick McHardy's message of "Fri\, 06 Mar 2009 16\:33\:08 +0100")
Patrick McHardy <kaber@trash.net> writes:
> Eric W. Biederman wrote:
>> Patrick McHardy <kaber@trash.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
next prev parent reply other threads:[~2009-03-06 15:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-05 23:12 [PATCH] macvlan: Support creating macvlans from macvlans Eric W. Biederman
2009-03-06 13:54 ` Patrick McHardy
2009-03-06 14:17 ` Eric W. Biederman
2009-03-06 14:25 ` Patrick McHardy
2009-03-06 15:03 ` Eric W. Biederman
2009-03-06 15:08 ` Patrick McHardy
2009-03-06 15:24 ` Eric W. Biederman
2009-03-06 15:33 ` Patrick McHardy
2009-03-06 15:50 ` Eric W. Biederman [this message]
2009-03-06 15:56 ` Patrick McHardy
2009-03-06 17:07 ` Ben Greear
2009-03-06 20:16 ` [PATCH] macvlan: Deterministic ingress packet delivery Eric W. Biederman
2009-03-07 16:36 ` Ben Greear
2009-03-09 13:25 ` Patrick McHardy
2009-03-13 20:16 ` David Miller
2009-03-13 20:15 ` [PATCH] macvlan: Support creating macvlans from macvlans David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1wsb2k5vg.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).