Date:	Wed, 25 Feb 2015 11:15:43 -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 Thu, Feb 26, 2015 at 12:21:47AM +0530, B Viswanath wrote:
> On 26 February 2015 at 00:09, Guenter Roeck <linux@...ck-us.net> wrote:
> > 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.
> 
> I didn't mean that the chips support L3 in hardware, as you said they
> don't. I meant that these chips are used in routers which have routing
> done by CPU. Typically the OPENWRT class devices, SOHO or similar
> devices.
> 
No, that is not the use case in any of the use cases I am aware of
and have been involved with.

> For these routers, exposing FDB to CPU is not really a requirement. So
> the hardware is not built to have learn/age-notifications or efficient
> access to FDB.  This is the reason I asked you whether the driver you
> are developing really needs to expose FDB to CPU.
> 
> >
> >> 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.
> 
> This is a general usecase and is usually with chips that can support
> learning notifications and other CPU controls on FDB. It can be
> implemented via bridge controlling the FDB. But I suspect this usecase
> won't be applicable for the device you are attempting to port the
> driver to.
> 

What do you mean with "bridge controlling the FDB" ? You mean by software ?
That would not scale for the reasons mentioned earlier; the switch chips
need to be able to populate their own FDBs.

Note that I am not that much concerned about "my" use cases, at least not
for now. For those cases, there will in general only be one port connected
to the CPU, and a bridge group is not shared across multiple ethernet ports
conneted to the CPU and some of the switch ports. But that doesn't mean
that we should ignore that possibility.

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