netdev - Re: [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing in SW or HW

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]

Message-ID: <CAN+pFwKft-f8wPuYbL7MB7O3UdqbKRACoEX44z4iM3BMkuu9eQ@mail.gmail.com>
Date:	Wed, 25 Feb 2015 23:01:00 +0530
From:	B Viswanath <marichika4@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
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 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
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 ?

> Agreed.
>
> Some of the Marvell chip support accessing its registers through Ethernet,
> so that may be an option. That is not supported on all chips, so it would
> not be a generic solution, but it may be worthwhile looking into.
>
> 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
--
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