[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3ineaoty4.fsf@luffy.cx>
Date: Thu, 16 Nov 2017 21:21:55 +0100
From: Vincent Bernat <bernat@...fy.cx>
To: Andrew Lunn <andrew@...n.ch>
Cc: Sarah Newman <srn@...mr.com>, Willy Tarreau <w@....eu>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
netdev@...r.kernel.org, roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net: bridge: add max_fdb_count
❦ 16 novembre 2017 20:23 +0100, Andrew Lunn <andrew@...n.ch> :
> struct net_bridge_fdb_entry is 40 bytes.
>
> My WiFi access point which is also a 5 port bridge, currently has 97MB
> free RAM. That is space for about 2.5M FDB entries. So even Roopa's
> 128K is not really a problem, in terms of memory.
I am also interested in Sarah's patch because we can now have bridge
with many ports through VXLAN. The FDB can be replicated to an external
daemon with BGP and the cost of each additional MAC address is therefore
higher than just a few bytes. It seems simpler to implement a limiting
policy early (at the port or bridge level).
Also, this is a pretty standard limit to have for a bridge (switchport
port-security maximum on Cisco, set interface X mac-limit on
Juniper). And it's not something easy to do with ebtables.
--
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)
Powered by blists - more mailing lists