netdev - RE: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device

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-next>] [day] [month] [year] [list]

Message-ID: <E4CD12F19ABA0C4D8729E087A761DC3505D7E13E@ORSMSX101.amr.corp.intel.com>
Date:	Wed, 26 Nov 2014 07:37:13 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [patch net-next v3 09/17] bridge: add API to notify bridge
 driver of learned FBD on offloaded device

> >>>
> >>> Is there any case where this fdb entry gets re-used and is no 
> >>> longer added by an external learning? Should we clear this flag somewhere?
> >>
> >> Once the FDB entry is marked "added_by_external_learn" it stays 
> >> marked as such until removed by aging cleanup process (or flushed 
> >> due to interface down, etc).  If aged out (and now deleted), the 
> >> FDB entry may come back either by SW learn or by HW learn.  If SW 
> >> learn comes first, and then HW learn, HW learn will override and 
> >> mark the existing FDB entry "added_by_external_learn".  So there is 
> >> take-over by HW but no give-back to SW.  And there is no explicit 
> >> clearing of the mark short of deleting the FDB entry.  The mark is 
> >> mostly for letting user's know which FDB entries where learned by 
> >> HW and synced to the bridge's FDB.
> >
> > Thanks, makes sense now. This is probably obvious in this context, 
> > but maybe it would not hurt to come up with a documentation that 
> > describe the offload API, FDB entry lifetime and HW/SW ownership etc...
> 
> I have an updated Documentation/networking/switchdev.txt that covers 
> the swdev APIs and usage and notes, but Jiri is being stingy with it.
> Will get this out, either in v4 or follow-on patches.  There is enough 
> going on just with L2 offload that we're going to need some good 
> documentation to guide implementers.
> --

To control the lifetime of an externally learned FDB entry, the bridge shall provide an API for the switch driver to update the freshness of externally learned entries. Otherwise, the bridge aging will age entries which are currently or frequently used by the HW.
Is this covered in the updated document?
Is this functionality planned for v4?