diff options
author | David S. Miller <davem@davemloft.net> | 2018-05-03 20:46:48 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-05-03 20:46:48 +0300 |
commit | 62264f99fbea555af5cd4d012bc5bb63e6d8fece (patch) | |
tree | e502263bda06c2ca20ae238414773447c015ef93 /net/packet | |
parent | 0e913f28ba56d29c65a95ac5d46f25c42f876db0 (diff) | |
parent | 161d82de1ff8430ef96d90d0da0e3643979791d2 (diff) | |
download | linux-62264f99fbea555af5cd4d012bc5bb63e6d8fece.tar.xz |
Merge branch 'bridge-FDB-Notify-about-removal-of-non-user-added-entries'
Petr Machata says:
====================
bridge: FDB: Notify about removal of non-user-added entries
Device drivers may generally need to keep in sync with bridge's FDB. In
particular, for its offload of tc mirror action where the mirrored-to
device is a gretap device, mlxsw needs to listen to a number of events,
FDB events among the others. SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be
a natural notification in that case.
However, for removal of FDB entries added due to device activity (as
opposed to explicit addition through "bridge fdb add" or similar), there
are no notifications.
Thus in patch #1, add the "added_by_user" field to switchdev
notifications sent for FDB activity. Adapt drivers to ignore activity on
non-user-added entries, to maintain the current behavior. Specifically
in case of mlxsw, allow mlxsw_sp_span_respin() call for any and all FDB
updates.
In patch #2, change the bridge driver to actually emit notifications for
these FDB entries. Take care not to send notification for bridge
updates that itself originate in SWITCHDEV_FDB_*_TO_BRIDGE events.
Changes from v1 to v2:
- Instead of introducing a new variant of fdb_delete(), add a new
parameter to the existing function.
- Name the parameter swdev_notify, not notify.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/packet')
0 files changed, 0 insertions, 0 deletions