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