Date:	Mon, 12 Jan 2015 11:00:13 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	Scott Feldman <sfeldma@...il.com>, Netdev <netdev@...r.kernel.org>
CC:	Jiri Pirko <jiri@...nulli.us>,
	Siva Mannem <siva.mannem.lnx@...il.com>,
	"marichika4@...il.com" <marichika4@...il.com>
Subject: RE: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
 fdb entries learnt via br_fdb_external_learn_add()



>-----Original Message-----
>From: Scott Feldman [mailto:sfeldma@...il.com]
>Sent: Saturday, January 10, 2015 10:29 PM
>To: Arad, Ronen
>Cc: Netdev; Jiri Pirko; Siva Mannem; marichika4@...il.com
>Subject: Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
>fdb entries learnt via br_fdb_external_learn_add()
>
>Perfect, I think we have a good working set of use-cases.  Thanks for
>adding those.  Your case 3 seems do-able without too much work since
>we already know which ones where externally added, just need another
>per-bridge-port flag to turn off bridging aging of externally learned
>entries.  This will address the performance issue you (and B
>Viswanath) raised.
> What about the entry stats, from the user's
>'bridge -s fdb show" perspective for the bridge fdb entries?  Will
>these numbers match expectations?  I think case 1 and case 4 provide a
>coherent stats view.  Case 3 seems to be lacking in this regard.
>
I think that statistics accuracy is orthogonal to the mechanism used for aging
in all the cases where learning sync is enabled (i.e. cases 1, 3, 4).  
Accuracy only depends on how frequent the switch port driver notifies the
bridge FDB. The best accuracy achievable is with updates once per-second. At 
the other extreme the switch port driver does not refresh entries. It only
notifies the bridge after entries are removed from the HW. In this extreme case
the statistics will really show the time since an entry was first learned and
not the time since it was last re-learned in HW. 
Switch port driver could pick some
acceptable rate to update the bridge module. Within a typical 5 minutes aging
interval, updates every 10 seconds or every 30 seconds could be a reasonable
tradeoff between statistics accuracy and system overhead.
  
>On Fri, Jan 9, 2015 at 10:51 PM, Arad, Ronen <ronen.arad@...el.com> wrote:
>> [...]
>>>> It is indeed simpler. However, if the overhead of reading hit bits from
>the
>>>HW
>>>> and updating freshness of entries using br_fdb_external_learn_add() is too
>>>> expensive, it would force such platforms to disable learning sync
>>>altogether.
>>>> Therefore, I believe aging offload flag (could be sufficient at bridge
>>>level)
>>>> and external aging interval (possibly longer than the software aging
>>>interval)
>>>> will encourage drivers to use leaning sync.
>>>>>-scott
>>>
>>>I'm not sure I follow that last part.
>>>
>>>Can we list out the use-cases to see what's missing?
>>>
>>>Case 1: bridge ages out learned_sync'ed entries
>>>
>>>bridge port learning: off
>>>offload port learning: on
>>>offload port learning_sync: on
>>>
>>>Driver calls br_fdb_external_learn_add() periodically to refresh
>>>bridge fdb entry
>>>to keep it from going stale.
>>>Bridge removes aged out fdb entries (and indirectly tells offload
>>>device to do the same).
>>>
>>>Case 2: offload device/bridge age out entries independently
>>>
>>>bridge port learning: on
>>>offload port learning: on
>>>offload port learning_sync: off
>>>
>>>Bridge ages out its stale learned entries, independent of offload device.
>>>Offload device ages out its stale learned entries, independent of bridge.
>>>
>>>Case 3: ?
>>>
>>>Please help me finish the use-case list so we can see what's missing.
>>
>>
>> Case 3: offload device ages out external entries and notifies bridge
>>
>> bridge port learning: on or off (Bridge only learns from packets seen
>(Rx/Tx))
>> offload port learning: on
>> offload port learning_sync: on
>> bridge aging of external learn: off
>> offload device aging: on
>>
>> Switch port/device driver ages entries (could be by HW aging or soft aging
>in
>> driver/firmware),
>> notifies bridge about aged entries using br_fdb_externallearn_del().
>> This allows efficient HW aging and batched notification at a pace
>independent
>> of bridge aging interval.
>> User still enjoys a single VLAN-aware FDB within the bridge module and
>having
>> all entries in one place. Externally learned entries are identified as such
>by
>> iproute2 "bridge fdb show" command. Device does not have to implement
>> ndo_bridge_fdb_dump() for each offload port as the bridge module provides it
>> for the common FDB.
>>
>> Case 4: bridge ages owned and external entries at different intervals
>>
>> bridge port learning: on (Effectively only for Rx/Tx traffic seen by
>>                           software bridge)
>> offload port learning: on (transient traffic and RxTx, overlap with bridge
>>                            learned entries possible)
>> offload port learning_sync: on
>> bridge aging of external learn: on
>> offload device aging: off
>> bridge aging interval for owned entries: T1
>> bridge aging interval for external entries: T2 (Typically T2 > T1)
>>
>> This allows for fine-tuning the overhead of periodic updates of entries
>> freshness from offload port device.
>>
>> The bottom line of cases 3-4 is that it is desirable to use the common
>bridge
>> FDB as long as bridge aging of externally learned entries could be
>controlled
>> by the offload device: Either be at a longer interval or disabled.
>>
>>>
>>>-scott
>>>--
>>>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