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

Date:	Thu, 27 Nov 2014 07:37:21 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	"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



> -----Original Message-----
> From: Scott Feldman [mailto:sfeldma@...il.com]
> Sent: Wednesday, November 26, 2014 11:04 PM
> To: Arad, Ronen
> Cc: 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
> 
> On Tue, Nov 25, 2014 at 9:37 PM, Arad, Ronen <ronen.arad@...el.com>
> wrote:
> >> >>>
> >> >>> 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?
> 
> Hi Ronen,
> 
> It's already there: driver calls br_fdb_external_learn_add() to refresh FBD
> entry, which updates the fdb->updated and fdb->used timestamps,
> preventing bridge from prematurely aging out the entry.
> We'll make sure that detail gets in the doc.  It's up to the driver on how
> frequently it calls br_fdb_external_learn_add().  Maybe it just blindly makes
> the call every 1s.  That's what rocker driver does (as long as the FDB entry
> continues to get hits).  From the user's perspective, 1s update is nice when
> looking at the stats dump for fdbs, since the timestamps are in secs.
> 
> -scott

Hi Scott,

Thanks. This should work. I overlooked that but now I see it in the code with a clear comment.

-ronen