[v1,0/5] IDPF Virtchnl fixes

Message

Manoj Vishwanathan Aug. 13, 2024, 6:27 p.m. UTC

This patch series is to enhance IDPF virtchnl error reporting and some
minor fixes to the locking sequence in virtchnl message handling
we encountered while testing.
Also includes a minor clean up with regards to warning we encountered
in controlq section of IDPF.

The issue we had here was a virtchnl processing delay leading to the
"xn->salt" mismatch, transaction timeout and connection not recovering.
This was due to default CPU bounded kworker workqueue for virtchnl message
processing being starved by aggressive userspace load causing the
virtchnl processing to be delayed and causing a transaction timeout.
The reason the virtchnl process kworker was stalled as it
was bound to CPU0 by default and there was immense IRQ traffic to CPU0.
All of the above with an aggressive user space process on the same core
lead to the change from Marco Leogrande to convert the idpf workqueues
to unbound.


Manoj Vishwanathan (3):
  idpf: address an rtnl lock splat in tx timeout recovery path
  idpf: Acquire the lock before accessing the xn->salt
  idpf: more info during virtchnl transaction time out

Marco Leogrande (1):
  idpf: convert workqueues to unbound

Willem de Bruijn (1):
  idpf: warn on possible ctlq overflow

 drivers/net/ethernet/intel/idpf/idpf_main.c   | 15 ++++++++-----
 drivers/net/ethernet/intel/idpf/idpf_txrx.c   | 14 ++++++++++++-
 .../net/ethernet/intel/idpf/idpf_virtchnl.c   | 21 ++++++++++++++-----
 3 files changed, 39 insertions(+), 11 deletions(-)

Comments

Tony Nguyen Aug. 15, 2024, 10:55 p.m. UTC | #1

On 8/13/2024 11:27 AM, Manoj Vishwanathan wrote:

Hi Manoj,

It would be great if you could familiarize yourself with the netdev process:

https://docs.kernel.org/process/maintainer-netdev.html#netdev-faq

For the Intel drivers, we follow the same guidelines other than we use 
iwl-net|iwl-next rather than net|net-next respectively.


> This patch series is to enhance IDPF virtchnl error reporting and some
> minor fixes to the locking sequence in virtchnl message handling
> we encountered while testing.
> Also includes a minor clean up with regards to warning we encountered
> in controlq section of IDPF.

The bug fixes should be broken out and designated for iwl-net and the 
others to iwl-next. Fix patches should include a Fixes: tag.

Also, please use RCT for networking patches (patch 1).

Thanks,
Tony

> The issue we had here was a virtchnl processing delay leading to the
> "xn->salt" mismatch, transaction timeout and connection not recovering.
> This was due to default CPU bounded kworker workqueue for virtchnl message
> processing being starved by aggressive userspace load causing the
> virtchnl processing to be delayed and causing a transaction timeout.
> The reason the virtchnl process kworker was stalled as it
> was bound to CPU0 by default and there was immense IRQ traffic to CPU0.
> All of the above with an aggressive user space process on the same core
> lead to the change from Marco Leogrande to convert the idpf workqueues
> to unbound.
> 
> Manoj Vishwanathan (3):
>    idpf: address an rtnl lock splat in tx timeout recovery path
>    idpf: Acquire the lock before accessing the xn->salt
>    idpf: more info during virtchnl transaction time out
> 
> Marco Leogrande (1):
>    idpf: convert workqueues to unbound
> 
> Willem de Bruijn (1):
>    idpf: warn on possible ctlq overflow
> 
>   drivers/net/ethernet/intel/idpf/idpf_main.c   | 15 ++++++++-----
>   drivers/net/ethernet/intel/idpf/idpf_txrx.c   | 14 ++++++++++++-
>   .../net/ethernet/intel/idpf/idpf_virtchnl.c   | 21 ++++++++++++++-----
>   3 files changed, 39 insertions(+), 11 deletions(-)
>