All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Vincent Bernat <bernat@luffy.cx>
Cc: Andrew Lunn <andrew@lunn.ch>, 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 16:27:18 -0800	[thread overview]
Message-ID: <20171116162718.3c252ff1@xeon-e3> (raw)
In-Reply-To: <m3ineaoty4.fsf@luffy.cx>

On Thu, 16 Nov 2017 21:21:55 +0100
Vincent Bernat <bernat@luffy.cx> wrote:

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

I want an optional limit per port, it makes a lot of sense.
If for no other reason that huge hash tables are a performance problems.

There is a bigger question about which fdb to evict but just dropping the
new one seems to be easiest and as good as any other solution.

  reply	other threads:[~2017-11-17  0:27 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
2017-11-17  0:27             ` Stephen Hemminger [this message]
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=20171116162718.3c252ff1@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=andrew@lunn.ch \
    --cc=bernat@luffy.cx \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.