[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN+pFwJQQMFmmm1f7tSPCmaSr2GE_L8Pua+Rz7tvK9CFnr63Tg@mail.gmail.com>
Date: Thu, 5 Feb 2015 16:35:27 +0530
From: B Viswanath <marichika4@...il.com>
To: Siva Mannem <siva.mannem.lnx@...il.com>
Cc: David Miller <davem@...emloft.net>,
Scott Feldman <sfeldma@...il.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Netdev <netdev@...r.kernel.org>,
Jiří Pírko <jiri@...nulli.us>
Subject: Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt
FDB entries, they are removed when 'external' entity notifies the aging
On 5 February 2015 at 15:56, Siva Mannem <siva.mannem.lnx@...il.com> wrote:
> On Thu, Feb 5, 2015 at 1:23 PM, David Miller <davem@...emloft.net> wrote:
>> From: Scott Feldman <sfeldma@...il.com>
>> Date: Wed, 4 Feb 2015 23:13:07 -0800
>>
>>> I'd like to see this patch reverted so we can have a more
>>> comprehensive discussion/solution. With this patch applied, the only
>>> user (rocker) of NETDEV_SWITCH_FDB_ADD is broken. So please undo this
>>> patch so rocker isn't broken and let's work on a knob to suit both
>>> modes: 1) let bridge manage aging, 2) let device manage aging.
>>
>> Patch reverted.
>
> I now see why rocker is broken. Sorry for the churn.
> As Scott/Roopa suggested, a new flag IFLA_BRPORT_AGING_SYNC (similar
> to IFLA_BRPORT_LEARNING_SYNC) can be defined and stored in
> net_bridge_port->flags when user configures it. Some thing like below.
>
> $ sudo bridge link set dev swp1 ageing_sync on self
>
> And bridge ageing logic does not age externally learnt entry *only* if
> IFLA_BRPORT_AGING_SYNC flag on fdb entry's net_bridge_port is set.
> This ensures that existing behavior continues to be default behavior
> and is of no harm to rocker.
>
> Please let me know your comments on above approach.
I am not sure you really want to pass on this burden of deciding who
should age to the end user. I think user should not be forced to be
aware of all the device and driver properties.
May be a different way would be that -
1. driver specifies whether it can supporting ageing by itself (the
chip) during registration.
2. driver also allows that kernel turn off the driver/device ageing.
3. when a bridge is created with all ports from same device which
supports ageing (and which is currently enabled), then bridge defers
ageing to driver. Otherwise bridge disables ageing on all
participating devices and takes care of ageing by itself.
4. When ageing is disabled on a device, all other bridges that use any
ports from that device start ageing themselves.
I guess this sounds complicated, but it can ensure that user gets the
best default behaviour based on the device. Any alternate suggestions
?
Thanks
vissu
> --
> Regards,
> Siva Mannem.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists