[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1729786087.git.petrm@nvidia.com>
Date: Thu, 24 Oct 2024 18:57:35 +0200
From: Petr Machata <petrm@...dia.com>
To: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, <netdev@...r.kernel.org>
CC: Ido Schimmel <idosch@...dia.com>, Petr Machata <petrm@...dia.com>, "Amit
Cohen" <amcohen@...dia.com>, Vladimir Oltean <vladimir.oltean@....com>, "Andy
Roulin" <aroulin@...dia.com>, <mlxsw@...dia.com>
Subject: [PATCH net-next v2 0/8] net: Shift responsibility for FDB notifications to drivers
Currently when FDB entries are added to or deleted from a VXLAN netdevice,
the VXLAN driver emits one notification, including the VXLAN-specific
attributes. The core however always sends a notification as well, a generic
one. Thus two notifications are unnecessarily sent for these operations. A
similar situation comes up with bridge driver, which also emits
notifications on its own.
# ip link add name vx type vxlan id 1000 dstport 4789
# bridge monitor fdb &
[1] 1981693
# bridge fdb add de:ad:be:ef:13:37 dev vx self dst 192.0.2.1
de:ad:be:ef:13:37 dev vx dst 192.0.2.1 self permanent
de:ad:be:ef:13:37 dev vx self permanent
In order to prevent this duplicity, shift the responsibility to send the
notification always to the drivers. Only where the default FDB add / del
operations are used does the core emit notifications. If fdb_add and
fdb_del are overridden, the driver should do that instead.
To facilitate upholding this new responsibility, export rtnl_fdb_notify()
for drivers to use.
Besides this approach, we considered just passing a boolean back from the
driver, which would indicate whether the notification was done. But the
approach presented here seems cleaner.
Patches #1 to #3 are concerned with the above.
In the remaining patches, #4 to #8, add a selftest. This takes place across
several patches. Many of the helpers we would like to use for the test are
in forwarding/lib.sh, whereas net/ is a more suitable place for the test,
so the libraries need to be massaged a bit first.
v2:
- Patches #2, #3:
- Fix qlcnic build
Petr Machata (8):
net: rtnetlink: Publish rtnl_fdb_notify()
ndo_fdb_add: Shift responsibility for notifying to drivers
ndo_fdb_del: Shift responsibility for notifying to drivers
selftests: net: lib: Move logging from forwarding/lib.sh here
selftests: net: lib: Move tests_run from forwarding/lib.sh here
selftests: net: lib: Move checks from forwarding/lib.sh here
selftests: net: lib: Add kill_process
selftests: net: fdb_notify: Add a test for FDB notifications
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +
drivers/net/ethernet/intel/ice/ice_main.c | 6 +
drivers/net/ethernet/mscc/ocelot_net.c | 16 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_main.c | 12 +-
drivers/net/macvlan.c | 6 +
include/linux/netdevice.h | 5 +
include/linux/rtnetlink.h | 2 +
net/core/rtnetlink.c | 24 +-
.../drivers/net/mlxsw/devlink_trap.sh | 2 +-
.../net/mlxsw/devlink_trap_l3_drops.sh | 4 +-
.../net/mlxsw/devlink_trap_l3_exceptions.sh | 12 +-
.../net/mlxsw/devlink_trap_tunnel_ipip.sh | 4 +-
.../net/mlxsw/devlink_trap_tunnel_ipip6.sh | 4 +-
.../net/mlxsw/devlink_trap_tunnel_vxlan.sh | 4 +-
.../mlxsw/devlink_trap_tunnel_vxlan_ipv6.sh | 4 +-
.../selftests/drivers/net/mlxsw/tc_sample.sh | 4 +-
.../net/netdevsim/fib_notifications.sh | 6 +-
tools/testing/selftests/net/Makefile | 2 +-
.../selftests/net/drop_monitor_tests.sh | 2 +-
tools/testing/selftests/net/fdb_notify.sh | 95 ++++++++
tools/testing/selftests/net/fib_tests.sh | 8 +-
.../selftests/net/forwarding/devlink_lib.sh | 2 +-
tools/testing/selftests/net/forwarding/lib.sh | 199 +---------------
.../selftests/net/forwarding/tc_police.sh | 8 +-
tools/testing/selftests/net/lib.sh | 223 ++++++++++++++++++
25 files changed, 411 insertions(+), 246 deletions(-)
create mode 100755 tools/testing/selftests/net/fdb_notify.sh
--
2.45.0
Powered by blists - more mailing lists