[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d06e629-3d6b-98dc-fecc-c5336c434d81@blackwall.org>
Date: Thu, 21 Sep 2023 15:51:45 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Johannes Nixdorf <jnixdorf-oss@....de>,
"David S. Miller" <davem@...emloft.net>,
Andrew Lunn <andrew@...n.ch>, David Ahern <dsahern@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
Ido Schimmel <idosch@...dia.com>,
Jakub Kicinski <kuba@...nel.org>,
Oleksij Rempel <linux@...pel-privat.de>,
Paolo Abeni <pabeni@...hat.com>,
Roopa Prabhu <roopa@...dia.com>, Shuah Khan <shuah@...nel.org>,
Vladimir Oltean <vladimir.oltean@....com>
Cc: bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v4 4/6] net: bridge: Add netlink knobs for number
/ max learned FDB entries
On 9/21/23 15:41, Nikolay Aleksandrov wrote:
> On 9/19/23 11:12, Johannes Nixdorf wrote:
>> The previous patch added accounting and a limit for the number of
>> dynamically learned FDB entries per bridge. However it did not provide
>> means to actually configure those bounds or read back the count. This
>> patch does that.
>>
>> Two new netlink attributes are added for the accounting and limit of
>> dynamically learned FDB entries:
>> - IFLA_BR_FDB_N_LEARNED (RO) for the number of entries accounted for
>> a single bridge.
>> - IFLA_BR_FDB_MAX_LEARNED (RW) for the configured limit of entries for
>> the bridge.
>>
>> The new attributes are used like this:
>>
>> # ip link add name br up type bridge fdb_max_learned 256
>> # ip link add name v1 up master br type veth peer v2
>> # ip link set up dev v2
>> # mausezahn -a rand -c 1024 v2
>> 0.01 seconds (90877 packets per second
>> # bridge fdb | grep -v permanent | wc -l
>> 256
>> # ip -d link show dev br
>> 13: br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 [...]
>> [...] fdb_n_learned 256 fdb_max_learned 256
>>
>> Signed-off-by: Johannes Nixdorf <jnixdorf-oss@....de>
>> ---
>> include/uapi/linux/if_link.h | 2 ++
>> net/bridge/br_netlink.c | 15 ++++++++++++++-
>> 2 files changed, 16 insertions(+), 1 deletion(-)
[snip]
>> @@ -1670,7 +1680,10 @@ static int br_fill_info(struct sk_buff *skb,
>> const struct net_device *brdev)
>> nla_put_u8(skb, IFLA_BR_TOPOLOGY_CHANGE_DETECTED,
>> br->topology_change_detected) ||
>> nla_put(skb, IFLA_BR_GROUP_ADDR, ETH_ALEN, br->group_addr) ||
>> - nla_put(skb, IFLA_BR_MULTI_BOOLOPT, sizeof(bm), &bm))
>> + nla_put(skb, IFLA_BR_MULTI_BOOLOPT, sizeof(bm), &bm) ||
>> + nla_put_u32(skb, IFLA_BR_FDB_N_LEARNED,
>> + atomic_read(&br->fdb_n_learned)) ||
>> + nla_put_u32(skb, IFLA_BR_FDB_MAX_LEARNED, br->fdb_max_learned))
>> return -EMSGSIZE;
>> #ifdef CONFIG_BRIDGE_VLAN_FILTERING
>>
>
> Actually you're using atomic for counting, but using a u32 for the
> limit, you should cap it because the count can overflow. Or you should
> use atomic64 for the counting.
>
Scratch all that, I'm speaking nonsense. Need to refresh my mind. :)
EVerything's alright. Sorry for the noise.
Powered by blists - more mailing lists