On Thu, Feb 19, 2015 at 10:20:58PM -0500, Andy Gospodarek wrote:

On Thu, Feb 19, 2015 at 06:00:22PM -0800, 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)?

Yes, the setting of the BR_LEARNING_SYNC bit in bridge port flags should
signal to the hardware that it should send learning notifications up to
the kernel bridge.  This is set via the IFLA_BRPORT_LEARNING attribute
in a setlink message.

Sorry I should offer some clarification on this point.  The flag I
mentioned is only used to signal to drivers that they should notify the
core kernel about new MACs that are learned.

If there is a need for different driver behavior depending on whether
hardware learning is enabled or not it might be time to add a
configuration option up into the stack.