From: Vincent Bernat <bernat@luffy.cx>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Sarah Newman <srn@prgmr.com>, Willy Tarreau <w@1wt.eu>,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
netdev@vger.kernel.org, roopa <roopa@cumulusnetworks.com>
Subject: Re: [PATCH] net: bridge: add max_fdb_count
Date: Thu, 16 Nov 2017 21:21:55 +0100 [thread overview]
Message-ID: <m3ineaoty4.fsf@luffy.cx> (raw)
In-Reply-To: <20171116192325.GA16122@lunn.ch> (Andrew Lunn's message of "Thu, 16 Nov 2017 20:23:25 +0100")
❦ 16 novembre 2017 20:23 +0100, Andrew Lunn <andrew@lunn.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)
next prev parent reply other threads:[~2017-11-16 20:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 19:27 [PATCH] net: bridge: add max_fdb_count Sarah Newman
2017-11-15 19:43 ` Sarah Newman
2017-11-15 20:04 ` Stephen Hemminger
2017-11-16 2:25 ` Andrew Lunn
2017-11-16 4:05 ` Toshiaki Makita
2017-11-16 4:54 ` Sarah Newman
2017-11-16 6:13 ` Toshiaki Makita
2017-11-16 6:20 ` Roopa Prabhu
2017-11-16 16:54 ` Stephen Hemminger
2017-11-15 21:34 ` Egil Hjelmeland
2017-11-16 3:01 ` Andrew Lunn
2017-11-16 7:31 ` Nikolay Aleksandrov
2017-11-16 9:20 ` Sarah Newman
2017-11-16 9:49 ` Nikolay Aleksandrov
2017-11-16 9:58 ` Willy Tarreau
2017-11-16 18:23 ` Sarah Newman
2017-11-16 19:23 ` Andrew Lunn
2017-11-16 19:36 ` Nikolay Aleksandrov
2017-11-16 20:54 ` Sarah Newman
2017-11-16 20:21 ` Vincent Bernat [this message]
2017-11-17 0:27 ` Stephen Hemminger
2017-11-17 5:26 ` Willy Tarreau
2017-11-17 6:14 ` Nikolay Aleksandrov
2017-11-17 8:01 ` Nikolay Aleksandrov
2017-11-17 14:06 ` Andrew Lunn
2017-11-17 18:44 ` Willy Tarreau
2017-11-21 14:53 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ineaoty4.fsf@luffy.cx \
--to=bernat@luffy.cx \
--cc=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=srn@prgmr.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).