[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <133ACD1C-F64D-499B-BE66-4EDA3598A35C@blackwall.org>
Date: Sat, 09 Apr 2022 15:36:59 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: netdev@...r.kernel.org
CC: roopa@...dia.com, kuba@...nel.org, davem@...emloft.net,
bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next 0/6] net: bridge: add flush filtering support
On 9 April 2022 13:58:51 EEST, Nikolay Aleksandrov <razor@...ckwall.org> wrote:
>Hi,
>This patch-set adds support to specify filtering conditions for a flush
>operation. Initially only FDB flush filtering is added, later MDB
>support will be added as well. Some user-space applications need a way
>to delete only a specific set of entries, e.g. mlag implementations need
>a way to flush only dynamic entries excluding externally learned ones
>or only externally learned ones without static entries etc. Also apps
>usually want to target only a specific vlan or port/vlan combination.
>The current 2 flush operations (per port and bridge-wide) are not
>extensible and cannot provide such filtering, so a new bridge af
>attribute is added (IFLA_BRIDGE_FLUSH) which contains the filtering
>information for each object type which has to be flushed.
>An example structure for fdbs:
> [ IFLA_BRIDGE_FLUSH ]
> `[ BRIDGE_FDB_FLUSH ]
> `[ FDB_FLUSH_NDM_STATE ]
> `[ FDB_FLUSH_NDM_FLAGS ]
>
>I decided against embedding these into the old flush attributes for
>multiple reasons - proper error handling on unsupported attributes,
>older kernels silently flushing all, need for a second mechanism to
>signal that the attribute should be parsed (e.g. using boolopts),
>special treatment for permanent entries.
>
>Examples:
>$ bridge fdb flush dev bridge vlan 100 static
>< flush all static entries on vlan 100 >
>$ bridge fdb flush dev bridge vlan 1 dynamic
>< flush all dynamic entries on vlan 1 >
>$ bridge fdb flush dev bridge port ens16 vlan 1 dynamic
>< flush all dynamic entries on port ens16 and vlan 1 >
>$ bridge fdb flush dev bridge nooffloaded nopermanent
>< flush all non-offloaded and non-permanent entries >
>$ bridge fdb flush dev bridge static noextern_learn
>< flush all static entries which are not externally learned >
>$ bridge fdb flush dev bridge permanent
>< flush all permanent entries >
>
>Note that all flags have their negated version (static vs nostatic etc)
>and there are some tricky cases to handle like "static" which in flag
>terms means fdbs that have NUD_NOARP but *not* NUD_PERMANENT, so the
>mask matches on both but we need only NUD_NOARP to be set. That's
>because permanent entries have both set so we can't just match on
>NUD_NOARP. Also note that this flush operation doesn't treat permanent
>entries in a special way (fdb_delete vs fdb_delete_local), it will
>delete them regardless if any port is using them. We can extend the api
>with a flag to do that if needed in the future.
>
>Patches in this set:
> 1. adds the new IFLA_BRIDGE_FLUSH bridge af attribute
> 2. adds a basic structure to describe an fdb flush filter
> 3. adds fdb netlink flush call via BRIDGE_FDB_FLUSH attribute
> 4 - 6. add support for specifying various fdb fields to filter
>
>Patch-sets (in order):
> - Initial flush infra and fdb flush filtering (this set)
> - iproute2 support
> - selftests
>
>Future work:
> - mdb flush support
>
>Thanks,
> Nik
>
>Nikolay Aleksandrov (6):
> net: bridge: add a generic flush operation
> net: bridge: fdb: add support for fine-grained flushing
> net: bridge: fdb: add new nl attribute-based flush call
> net: bridge: fdb: add support for flush filtering based on ndm flags
> and state
> net: bridge: fdb: add support for flush filtering based on ifindex
> net: bridge: fdb: add support for flush filtering based on vlan id
>
> include/uapi/linux/if_bridge.h | 22 ++++++
> net/bridge/br_fdb.c | 128 +++++++++++++++++++++++++++++++--
> net/bridge/br_netlink.c | 59 ++++++++++++++-
> net/bridge/br_private.h | 12 +++-
> net/bridge/br_sysfs_br.c | 6 +-
> 5 files changed, 215 insertions(+), 12 deletions(-)
>
Actually if you prefer I can send the selftests with this set, I'm used to sending them last
after the iproute2 support is finalised. :)
Cheers,
Nik
Powered by blists - more mailing lists