On Thu, Feb 19, 2015 at 11:05 PM, Guenter Roeck [off-list ref] wrote:

On Thu, Feb 19, 2015 at 06:41:34PM -0800, roopa wrote:

quoted

On 2/19/15, 6:00 PM, Florian Fainelli wrote:

quoted

On 19/02/15 17:46, roopa wrote:

quoted

On 2/19/15, 5:03 PM, Guenter Roeck wrote:

quoted

On Thu, Feb 19, 2015 at 04:51:30PM -0800, roopa wrote:

quoted

quoted

Not sure yet what to do about setting the fdb aging time. I don't see a
mechanism to do that. No idea how important that is.

rocker, the only consumer today relies on the bridge driver aging of
learnt
entries.
You could do the same.

Remember that we are dealing with hardware switch chips. Those chips
won't time out fdb entries just because the kernel's bridge driver
thinks that it should.

Oh, they dont..?. sorry,  I dont know the details about your hardware.
But, if these are entries learnt by hw, there should be a hw config to
age them (I guess that is what you are talking about). Which the swicth
driver can set.
If you disable hw aging, you can sync these entries to the bridge
driver, and make the bridge driver age them followed by a subsequent
delete in hw.

The SF2 HW has and aging and a valid bit available, I guess my question
would be, do we have anything today in "net-next" that allows
configuring HW aging vs. SW aging (implying doing a HW to SW sync)?

There is no config parameter to set HW aging vs SW aging. But if you want SW
aging, an example is the rocker implementation today.
And there is BR_LEARNING_SYNC per bridge port flag to sync HW to SW using
notifiers (see rocker).

SW aging is not practical. In my specific use case there can be 800+ mac
addresses in a single mac domain, connected through an mdio bus on gpio pins.
Besides, it doesn't really make much sense to burden SW with something that
can easily be handled in HW, just because SW doesn't have the means to pass
the necessary parameter - aging time - to the HW.

I have a patch which I'll post shortly as an RFC that addresses ageing
either by SW or by HW.

-scott