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

Powered by blists - more mailing lists