This is an implementation of the idea provided by Jakub here

https://lore.kernel.org/netdev/[email protected]/

ndo_set_rx_mode is problematic because it cannot sleep. 

To address this, this series proposes dividing the concept of setting
rx_mode into 2 stages: snapshot and deferred I/O. To achieve this, we
change the semantics of set_rx_mode and add a new ndo write_rx_mode.

The new set_rx_mode will be responsible for customizing the rx_mode
snapshot which will be used by write_rx_mode to update the hardware

This refactor has the secondary benefit of stopping set rx_mode
requests from building up as only the most recent request (before the
work has gotten a chance to run) will be confirmed/executed.

In brief, the new flow will look something like:

set_rx_mode():
    ndo_set_rx_mode();
    prepare_rx_mode();

write_rx_mode():
    use_snapshot();
    ndo_write_rx_mode();

write_rx_mode() is called from a work item and doesn't hold the 
netif_addr_lock spin lock during ndo_write_rx_mode() making it sleepable
in that section.

This model should work correctly if the following conditions hold:

1. write_rx_mode should use the rx_mode set by the most recent
    call to prepare_rx_mode() before its execution.

2. If a make_snapshot_ready call happens during execution of write_rx_mode,
    write_rx_mode() should be rescheduled.

3. All calls to modify rx_mode should pass through the prepare_rx_mode +
        schedule write_rx_mode() execution flow. netif_schedule_rx_mode_work()
    has been implemented in core for this purpose.

1 and 2 are implemented in core

Drivers need to ensure 3 using netif_schedule_rx_mode_work()

To use this model, a driver needs to implement the
ndo_write_rx_mode callback, change the set_rx_mode callback
appropriately and replace all calls to modify rx mode with
netif_schedule_rx_mode_work()

Signed-off-by: I Viswanath <[email protected]>
---

v1:
Link: 
https://lore.kernel.org/netdev/[email protected]/

v2:
- Exported set_and_schedule_rx_config as a symbol for use in modules
- Fixed incorrect cleanup for the case of rx_work alloc failing in 
alloc_netdev_mqs
- Removed the locked version (cp_set_rx_mode) and renamed __cp_set_rx_mode to 
cp_set_rx_mode
Link: 
https://lore.kernel.org/netdev/[email protected]/

v3:
- Added RFT tag
- Corrected mangled patch
Link: 
https://lore.kernel.org/netdev/[email protected]/

v4:
- Completely reworked the snapshot mechanism as per v3 comments
- Implemented the callback for virtio-net instead of 8139cp driver
- Removed RFC tag
Link: 
https://lore.kernel.org/netdev/[email protected]/

v5:
- Fix broken code and titles
- Remove RFT tag
Link: 
https://lore.kernel.org/netdev/[email protected]/

v6:
- Added struct netif_deferred_work_cleanup and members needs_deferred_cleanup 
and deferred_work_cleanup in net_device
- Moved out ctrl bits from netif_rx_mode_config to netif_rx_mode_work_ctx
Link: 
https://lore.kernel.org/netdev/[email protected]/

v7:
- Improved function, enum and struct names
Link: 
https://lore.kernel.org/netdev/[email protected]/

v8:
- Implemented the callback for drivers e1000, 8139cp, vmxnet3 and pcnet32
- Moved the rx_mode config set calls (for prom and allmulti) in prepare_rx_mode 
to the ndo_set_rx_mode callback for consistency
- Improved commit messages 

I Viswanath (6):
  net: refactor set_rx_mode into snapshot and deferred I/O
  virtio-net: Implement ndo_write_rx_mode callback
  e1000: Implement ndo_write_rx_mode callback
  8139cp: Implement ndo_write_rx_mode callback
  vmxnet3: Implement ndo_write_rx_mode callback
  pcnet32: Implement ndo_write_rx_mode callback

 drivers/net/ethernet/amd/pcnet32.c            |  57 +++-
 drivers/net/ethernet/intel/e1000/e1000_main.c |  59 ++--
 drivers/net/ethernet/realtek/8139cp.c         |  33 ++-
 drivers/net/virtio_net.c                      |  61 ++--
 drivers/net/vmxnet3/vmxnet3_drv.c             |  38 ++-
 include/linux/netdevice.h                     | 112 +++++++-
 net/core/dev.c                                | 265 +++++++++++++++++-
 7 files changed, 522 insertions(+), 103 deletions(-)

-- 
2.47.3


Reply via email to