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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150225143113.GD17992@lunn.ch>
Date:	Wed, 25 Feb 2015 15:31:13 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Scott Feldman <sfeldma@...il.com>
Cc:	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>,
	"linux@...ck-us.net" <linux@...ck-us.net>,
	"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

> Geunter had this question in the thread:
> 
> "I may be missing something, but I don't immediately see how this patch set
> helps me solve any of the problems I am seeing when integrating the Marvell
> switch code. Even if the switch internally does hardware aging, it still
> seems to me that we'll need software aging on top of that, even if the
> bridge code in the kernel has the same addresses in its fdb as the switch.
> I see no feasible means to keep the fdb in the switch synchronized
> with the fdb in the kernel".
> 
> 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.

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.

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