netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Manish Chopra <manish.chopra@qlogic.com>,
	Patrick McHardy <kaber@trash.net>
Cc: netdev <netdev@vger.kernel.org>, Yuval Mintz <Yuval.Mintz@qlogic.com>
Subject: Re: Question regarding MAC address configuraton with VLAN devices
Date: Tue, 07 Apr 2015 08:44:09 -0700	[thread overview]
Message-ID: <5523FB49.9010107@redhat.com> (raw)
In-Reply-To: <31AFFC7280259C4184970ABA9AFE8B93E0930C40@avmb3.qlogic.org>


On 04/01/2015 12:15 PM, Manish Chopra wrote:
> Hello Patrick,
>
> I have a question regarding MAC address configuration of network devices specially
> when VLANs are configured on that. Can you please help to address?
>
> When user changes MAC address of a base network device [e.g., via ifconfig]
> why existing VLAN device on top of that would add it's previous MAC address to
> unicast list of base device instead of adapting the new MAC address
> in it's own net device?
>
> What we are trying to achieve here is that -
>
> For a VF, if Hypervisor/Administrator has forced a MAC [e.g., via iproute2] then as a part of
> "learning process [of the new hypervisor forced mac] done by VF driver", it will simply call
> "call_netdevice_notifiers(NETDEV_CHANGEADDR, dev)", which would notify the address change
> to VLAN interfaces configured on top of VF device and they will adapt the hypervisor forced MAC too.
> But that's not seems to be the behavior here, instead VLAN device on top of the VF device seems to be adding
> It's previous MAC address to unicast list of base VF device. This configuration will not take effect
> [since PF is blocking the VF's additional unicast MACs, if once a MAC has been forced to the VF], thus
> effectively the VLAN interface will never receive traffic with it's configured MAC.
>
>
> Regards,
> Manish

What you are proposing would likely require significant changes to more 
than just VLANs.  It would have an impact on all stacked devices since 
normally the assumption is that we push addresses down, not up.  That is 
why the vlan_sync_address is simply checking to see if its current 
address is supported before pushing the address down.

Maybe we should look into adding some sort of flag to indicate that the 
address table is locked, like a IFF_L2_ADDR_LOCKED in order to indicate 
that the device only supports one L2 address and cannot be changed.  
Then you could probably pass that up to higher levels to force things 
like the address change you want in VLAN, and things like MACVLAN would 
simply fail if that flag is set.

- Alex

  parent reply	other threads:[~2015-04-07 15:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 19:15 Question regarding MAC address configuraton with VLAN devices Manish Chopra
2015-04-07 13:16 ` Manish Chopra
2015-04-07 15:44 ` Alexander Duyck [this message]
2015-04-08  5:49   ` Yuval Mintz
2015-04-08  9:20     ` Michal Kubecek
2015-04-08 10:16       ` Yuval Mintz

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=5523FB49.9010107@redhat.com \
    --to=alexander.h.duyck@redhat.com \
    --cc=Yuval.Mintz@qlogic.com \
    --cc=kaber@trash.net \
    --cc=manish.chopra@qlogic.com \
    --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).