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 12:28:36 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	"Arad, Ronen" <ronen.arad@...el.com>
Cc:	Netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>,
	Siva Mannem <siva.mannem.lnx@...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()

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.

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
--
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