[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJieiUjL=oeC7MTj4FfDxa35cC=vMEdFRR8ocGQoPqeaY6TCtw@mail.gmail.com>
Date: Wed, 15 Nov 2017 22:20:23 -0800
From: Roopa Prabhu <roopa@...ulusnetworks.com>
To: Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
Cc: Sarah Newman <srn@...mr.com>, Andrew Lunn <andrew@...n.ch>,
Stephen Hemminger <stephen@...workplumber.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH] net: bridge: add max_fdb_count
On Wed, Nov 15, 2017 at 10:13 PM, Toshiaki Makita
<makita.toshiaki@....ntt.co.jp> wrote:
> On 2017/11/16 13:54, Sarah Newman wrote:
>> On 11/15/2017 08:05 PM, Toshiaki Makita wrote:
>>> On 2017/11/16 11:25, Andrew Lunn wrote:
>>>>> Also what do the vendors using bridge for L2 offload to switch think?
>>>>
>>>> The Marvell L2 switches which DSA supports have 8K FDB/MDB entries. So
>>>> maybe 1024 is a bit low?
>>>
>>> How about U32_MAX by default since it is currently not restricted.
>>> (assuming the field will be changed to u32 as per Stephen's feedback).
>>>
>>> Otherwise users may suffer from unexpected behavior change by updating
>>> kernel?
>>>
>>
>> U32_MAX seems like much too high a default to be helpful to a typical user. How many devices are realistically on a single bridge in the wild? Double
>> that seems like a reasonable default.
>
> I'm suggesting the most unrealistic number to essentially disable the
> restriction by default.
> My understanding is that we put a priority on not to break existing
> users even if the new restriction looks reasonable for most people.
+1 , and yes, 1024 is very low. some of the switches we use support
around 128K FDB entries and we have seen that number increase fairly
quickly in newer generation switches. Default should be no limit to
not break existing users.
Powered by blists - more mailing lists