Re: [RFC] bridge: MAC learning uevents

2016-09-09 Thread Florian Fainelli
On 09/09/2016 01:51 AM, D. Herrendoerfer wrote: >> just like neighbor table modifications, it should be possible to listen for >> events with netlink. Doing it through uevent is the wrong model. > > I agree partially - but consider: > we plug hardware - we get an event > we remove hardware - we

Re: [RFC] bridge: MAC learning uevents

2016-09-09 Thread D. Herrendoerfer
> On Thu, 8 Sep 2016 11:30:08 -0700 > Florian Fainelli wrote: > >> On 09/08/2016 10:19 AM, D. Herrendoerfer wrote: >>> >>> On 08 Sep 2016, at 17:39, Stephen Hemminger >>> wrote: >>> On Thu, 8 Sep 2016 15:06:16 +0200 "D.

Re: [RFC] bridge: MAC learning uevents

2016-09-08 Thread Stephen Hemminger
On Thu, 8 Sep 2016 11:30:08 -0700 Florian Fainelli wrote: > On 09/08/2016 10:19 AM, D. Herrendoerfer wrote: > > > > On 08 Sep 2016, at 17:39, Stephen Hemminger > > wrote: > > > >> On Thu, 8 Sep 2016 15:06:16 +0200 > >> "D. Herrendoerfer"

Re: [RFC] bridge: MAC learning uevents

2016-09-08 Thread Florian Fainelli
On 09/08/2016 10:19 AM, D. Herrendoerfer wrote: > > On 08 Sep 2016, at 17:39, Stephen Hemminger > wrote: > >> On Thu, 8 Sep 2016 15:06:16 +0200 >> "D. Herrendoerfer" wrote: >> >>> Hello, >>> >>> I'd like to start a discussion if

Re: [RFC] bridge: MAC learning uevents

2016-09-08 Thread D. Herrendoerfer
There is a reference to the virtual port in the event so you can actually keep only one record MAC per port, I suppose the the impact would be the same if you do this to a macvtap device on top of an ethernet device. But granted - you could really load down the host. Dirk On 08 Sep 2016, at

Re: [RFC] bridge: MAC learning uevents

2016-09-08 Thread D. Herrendoerfer
On 08 Sep 2016, at 17:39, Stephen Hemminger wrote: > On Thu, 8 Sep 2016 15:06:16 +0200 > "D. Herrendoerfer" wrote: > >> Hello, >> >> I'd like to start a discussion if it makes sense to add an optional feature >> >> to the

Re: [RFC] bridge: MAC learning uevents

2016-09-08 Thread Stephen Hemminger
On Thu, 8 Sep 2016 15:06:16 +0200 "D. Herrendoerfer" 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

Re: [RFC] bridge: MAC learning uevents

2016-09-08 Thread Andi Kleen
"D. Herrendoerfer" writes: > > 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 ? What happens if someone floods the network with random mac addresses? Sounds like an

[RFC] bridge: MAC learning uevents

2016-09-08 Thread D. Herrendoerfer
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