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+pFwJZX1jbdyWiV6jamq9Tj_aiyCtpe8ETRtMfM-R6wuWbxQ@mail.gmail.com>
Date:	Thu, 26 Feb 2015 00:21:47 +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 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.

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.

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