From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH] net: bridge: add max_fdb_count
Date: Thu, 16 Nov 2017 16:27:18 -0800
Message-ID: <20171116162718.3c252ff1@xeon-e3>
References: <1510774027-2468-1-git-send-email-srn@prgmr.com>
        <4f31ae8b-352e-d2ab-cd71-4b31f76e666a@cumulusnetworks.com>
        <4d756a43-e51d-c52d-7b4b-fce61f021a66@prgmr.com>
        <20171116095846.GB14616@1wt.eu>
        <3d08c77f-8d71-e302-d3f7-24acc6df9414@prgmr.com>
        <20171116192325.GA16122@lunn.ch>
        <m3ineaoty4.fsf@luffy.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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>
To: Vincent Bernat <bernat@luffy.cx>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pg0-f67.google.com ([74.125.83.67]:36891 "EHLO
        mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753819AbdKQA1Z (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 16 Nov 2017 19:27:25 -0500
Received: by mail-pg0-f67.google.com with SMTP id o7so617976pgc.4
        for <netdev@vger.kernel.org>; Thu, 16 Nov 2017 16:27:25 -0800 (PST)
In-Reply-To: <m3ineaoty4.fsf@luffy.cx>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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

>  =E2=9D=A6 16 novembre 2017 20:23 +0100, Andrew Lunn <andrew@lunn.ch>=C2=
=A0:
>=20
> > 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. =20
>=20
> 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).
>=20
> 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.