[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54E76EFA.1050209@cumulusnetworks.com>
Date: Fri, 20 Feb 2015 09:29:30 -0800
From: roopa <roopa@...ulusnetworks.com>
To: sfeldma@...il.com
CC: netdev@...r.kernel.org, jiri@...nulli.us, linux@...ck-us.net,
f.fainelli@...il.com, andrew@...n.ch, gospo@...ulusnetworks.com,
vbandaru@...adcom.com, siva.mannem.lnx@...il.com
Subject: Re: [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing
in SW or HW
On 2/19/15, 11:09 PM, sfeldma@...il.com wrote:
> From: Scott Feldman <sfeldma@...il.com>
>
> Add a new NTF_EXT_FLAG to mark an FDB as externally aged, for example by
> offload hardware. Switchdev driver/devices can set this flag when learning a
> new FDB entry and SW (the bridge driver) will skip this entry when running its
> ageing task. If flag is set, the driver/device is responsible for calling
> call_netdev_switch_notifiers(NETDEV_SWITCH_FDB_DEL, ...) when entry expires.
>
> This give the flexibility for driver/device to decide ageing policy based on
> its capabilities. For devices managing many FDB entries, it is desireable for
> the device to aged out its own entries. Devices not capable of aged entries
> can rely of SW to age out the entries.
>
scott, patches look good. However, I am not sure yet if there is a need
to make it a per fdb entry flag.
At some point we will also need the hw ageing parameter to be configurable.
So other approach could be,
- ageing parameter on bridge gets offloaded the hw
- so, by default hw and kernel age their own entries using the same
bridge device default timer
- User can explicitly disable HW ageing by using self (this needs some
more thought because now the call is on the bridge device)
Thanks,
Roopa
--
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