netdev - RE: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Jan 2015 06:51:54 +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>
Subject: RE: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
 fdb entries learnt via br_fdb_external_learn_add()

[...]
>> 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