All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC] bridge: MAC learning uevents
Date: Thu, 8 Sep 2016 08:39:20 -0700	[thread overview]
Message-ID: <20160908083920.0d421951@xeon-e3> (raw)
In-Reply-To: <7824e091-6b1a-bf39-0f78-1c9084d59972@herrendoerfer.name>

On Thu, 8 Sep 2016 15:06:16 +0200
"D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> wrote:

> Hello,
> 
> I'd like to start a discussion if it makes sense to add an optional feature
> 
> to the bridge MAC address learning code to generate kernel uevents for
> 
> every learned (added) and removed MAC address.
> 
> The (my) rationale behind this is, that I work with multiport SRIOV and 
> MRIOV
> 
> network cards that cannot put each and every virtual port into promiscuous
> 
> mode, but they have the capability to register a large number of MAC 
> addresses
> 
> to each interface.
> 
> These systems are host to a large number of kvm guests, that require 
> network access.
> 
> To get around the problem I added two uevents to linuxbridge that would 
> announce every
> 
> learned address to udev, and udev would register or remove  the MAC 
> address to the
> 
> uplink device of the bridge.
> 
> The script may also add the required addresses for multicast and IPv6 if 
> required.
> 
> The need for promiscuous mode on the card was gone. All I needed to do 
> was to attach
> 
> the guests through a linuxbridge instead of directly to the card.
> 
> 
> I may be missing something here - I'm pretty sure there I am, but is 
> there any conceptual
> 
> reason why this should not be done this way ?
> 
> 
> I'm porting my patch (for 3.10.0) to head, and will make it available, I 
> just want some
> 
> valuable feedback as early as possible.
> 
> 
> Thanks, D.Herrendoerfer

This should be possible by listening for netlink events.
No need for udev interaction.

  parent reply	other threads:[~2016-09-08 15:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-08 13:06 [RFC] bridge: MAC learning uevents D. Herrendoerfer
2016-09-08 15:15 ` Andi Kleen
2016-09-08 17:23   ` D. Herrendoerfer
2016-09-08 15:39 ` Stephen Hemminger [this message]
2016-09-08 17:19   ` D. Herrendoerfer
2016-09-08 18:30     ` Florian Fainelli
2016-09-08 21:16       ` Stephen Hemminger
2016-09-09  8:51         ` D. Herrendoerfer
2016-09-09 23:54           ` Florian Fainelli

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=20160908083920.0d421951@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=d.herrendoerfer@herrendoerfer.name \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.