Three issues introduced by my recent asynchronous filter handling changes: 1. The old filter_rfs_insert would replace a matching filter of equal priority; we need to pass the appropriate argument to filter_insert to make it do the same. 2. We're lying to the kernel with our return value from ndo_rx_flow_steer, so we need to lie consistently when calling rps_may_expire_flow. This is only a partial fix, as the lie still prevents us from steering multiple flows with the same ID to different queues; a proper fix that stops us lying at all will hopefully follow later. 3. It's possible to cause the kernel to hammer ndo_rx_flow_steer very hard, so make sure we don't build up too huge a backlog of workitems.
Possibly it would be better to fix #3 on the kernel side; I have a patch which I think does that but it's not a regression in 4.17 so isn't 'net' material. There's also the issue that we come up in the bad configuration that triggers #3 by default, but that too is a problem for another time. Edward Cree (3): sfc: insert ARFS filters with replace_equal=true sfc: pass the correctly bogus filter_id to rps_may_expire_flow() sfc: limit ARFS workitems in flight per channel drivers/net/ethernet/sfc/ef10.c | 3 +- drivers/net/ethernet/sfc/farch.c | 2 +- drivers/net/ethernet/sfc/net_driver.h | 25 +++++++++++++++ drivers/net/ethernet/sfc/rx.c | 60 ++++++++++++++++++----------------- 4 files changed, 58 insertions(+), 32 deletions(-)
