Date:	Wed, 25 Feb 2015 10:39:39 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	B Viswanath <marichika4@...il.com>
Cc:	Andrew Lunn <andrew@...n.ch>, Scott Feldman <sfeldma@...il.com>,
	roopa <roopa@...ulusnetworks.com>,
	Viswanath Bandaru <vbandaru@...adcom.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"jiri@...nulli.us" <jiri@...nulli.us>,
	"gospo@...ulusnetworks.com" <gospo@...ulusnetworks.com>,
	"siva.mannem.lnx@...il.com" <siva.mannem.lnx@...il.com>
Subject: Re: [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing
 in SW or HW

On Wed, Feb 25, 2015 at 11:01:00PM +0530, B Viswanath wrote:
> On 25 February 2015 at 22:13, Guenter Roeck <linux@...ck-us.net> wrote:
> >
> <snip>
> 
> > > >
> > > > You'll want to turn learning off on the bridge, and enable learning (and
> > > > learning_sync) in hardware.  The hw driver will install an FDB entry in the
> > > > bridge's FDB and mark it "external".  The entry will also appear in the
> > > > device's FDB.
> > >
> > > I don't think this is going to work. There is no efficient way to get
> > > the hardware tables out of the hardware. We don't get notification of
> > > additions or removals. We can only read the whole table. And it can be
> > > expensive to read the whole table, since it can be 1K or more entries,
> > > going over an MDIO bus, which in the worst case can be bit banging on
> > > gpio lines.
> > >
> > Which, coincidentially, is the case in my application. The newer
> > Marvell switches support up to 8k forwarding table entries, so that
> > would be really awkward.
> >
> > > We probably need a design for devices where we can efficiently get
> > > access to the hardware table, and use it in the software bridge. But
> > > we also need a design where the SW and HW bridges have independently
> > > tables.
> > >
> 
> I do agree that reading all of FDB into CPU is a pain. Given the table
> size of 1K or 8K, I am (probably incorrectly) speculating that the
> device may be a router primarily. Also, not having means of

No. I don't think any of the Marvell or Broadcom entry level
switch chips supports L3.

See http://www.marvell.com/switching/link-street/ and
http://community.broadcom.com/docs/DOC-1724.

Forwarding table size in those chips is from 1k all the way up to 16k.

It is correct to assume that some of those chips are _used_ in
routers/L3 switches, but that would not be used for L3 data but
to interrconnect the various cards in the system, primarily for
internal management traffic.

> learn-notifications and/or a quick (hw) interface to get all the
> table, I (again probably incorrectly) speculate that there are not
> many use cases associated with FDB and end-user/CPU for this silicon.
> 
> So I am thinking why would you want to read FDB to CPU ? You can
> disable learning on the bridge and have the driver not send any
> learning notifications to kernel, while the silicon continues to learn
> and forward.  The end user may not be able see the FDB on a command,
> but is this a requirement for you ?
> 
> I may be missing some use cases here, so would you mind mentioning ?
> 
A bridge can span multiple switch chips as well as some local interfaces.
In that case, it would be beneficial if the switch would be able to share
its fdb with the CPU, but I don't think it is mandatory. I may be missing
something, though.

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