[net-next,0/8] net: Shift responsibility for FDB notifications to drivers

Message

Petr Machata Oct. 22, 2024, 2:50 p.m. UTC

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.


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  |  10 +-
 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, 409 insertions(+), 246 deletions(-)
 create mode 100755 tools/testing/selftests/net/fdb_notify.sh

Comments

Jakub Kicinski Oct. 29, 2024, 7:16 p.m. UTC | #1

On Tue, 22 Oct 2024 16:50:11 +0200 Petr Machata wrote:
> 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.

What about adding a bit to the ops struct to indicate that 
the driver will generate the notification? Seems smaller in 
terms of LoC and shifts the responsibility of doing extra
work towards more complex users.