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
> 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.
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"
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
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
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
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
"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
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