All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Kubiak <michal.kubiak@intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: maciej.fijalkowski@intel.com, emil.s.tantilov@intel.com,
	larysa.zaremba@intel.com, netdev@vger.kernel.org,
	Joshua Hay <joshua.a.hay@intel.com>,
	aleksander.lobakin@intel.com, intel-wired-lan@lists.osuosl.org,
	alan.brady@intel.com,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net] idpf: enable WB_ON_ITR
Date: Wed, 13 Dec 2023 14:23:19 +0100	[thread overview]
Message-ID: <ZXmwR4s25afUbwz3@localhost.localdomain> (raw)
In-Reply-To: <78ecdb9f-25e9-4847-87ed-6e8b44a7c71d@molgen.mpg.de>

On Tue, Dec 12, 2023 at 05:50:55PM +0100, Paul Menzel wrote:
> Dear Michal, dear Joshua,
> 
> 
> Thank you for your patch.
> 
> On 12/12/23 15:55, Michal Kubiak wrote:
> > From: Joshua Hay <joshua.a.hay@intel.com>
> > 
> > Tell hardware to writeback completed descriptors even when interrupts
> 
> Should you resend, the verb is spelled with a space: write back.

Sure, I will fix it.

> 
> > are disabled. Otherwise, descriptors might not be written back until
> > the hardware can flush a full cacheline of descriptors. This can cause
> > unnecessary delays when traffic is light (or even trigger Tx queue
> > timeout).
> 
> How can the problem be reproduced and the patch be verified?
> 
> 
> Kind regards,
> 
> Paul
> 
> 

Hi Paul,

To be honest, I have noticed the problem during the implementation of
AF_XDP feature for IDPF driver. In my scenario, I had 2 Tx queues:
 - regular LAN Tx queue
 - and XDP Tx queue
added to the same q_vector attached to the same NAPI, so those 2 Tx
queues were handled in the same NAPI poll loop.
Then, when I started a huge Tx zero-copy trafic using AF_XDP (on the XDP
queue), and, at the same time, tried to xmit a few packets using the second
(non-XDP) queue (e.g. with scapy), I was getting the Tx timeout on that regular
LAN Tx queue.
That is why I decided to upstream this fix. With disabled writebacks,
there is no chance to get the completion descriptor for the queue where
the traffic is much lighter.

I have never tried to reproduce the scenario described by Joshua
in his original patch ("unnecessary delays when traffic is light").

Thanks,
Michal

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

WARNING: multiple messages have this Message-ID (diff)
From: Michal Kubiak <michal.kubiak@intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Joshua Hay <joshua.a.hay@intel.com>,
	<intel-wired-lan@lists.osuosl.org>,
	<maciej.fijalkowski@intel.com>, <emil.s.tantilov@intel.com>,
	<larysa.zaremba@intel.com>, <netdev@vger.kernel.org>,
	<aleksander.lobakin@intel.com>, <alan.brady@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net] idpf: enable WB_ON_ITR
Date: Wed, 13 Dec 2023 14:23:19 +0100	[thread overview]
Message-ID: <ZXmwR4s25afUbwz3@localhost.localdomain> (raw)
In-Reply-To: <78ecdb9f-25e9-4847-87ed-6e8b44a7c71d@molgen.mpg.de>

On Tue, Dec 12, 2023 at 05:50:55PM +0100, Paul Menzel wrote:
> Dear Michal, dear Joshua,
> 
> 
> Thank you for your patch.
> 
> On 12/12/23 15:55, Michal Kubiak wrote:
> > From: Joshua Hay <joshua.a.hay@intel.com>
> > 
> > Tell hardware to writeback completed descriptors even when interrupts
> 
> Should you resend, the verb is spelled with a space: write back.

Sure, I will fix it.

> 
> > are disabled. Otherwise, descriptors might not be written back until
> > the hardware can flush a full cacheline of descriptors. This can cause
> > unnecessary delays when traffic is light (or even trigger Tx queue
> > timeout).
> 
> How can the problem be reproduced and the patch be verified?
> 
> 
> Kind regards,
> 
> Paul
> 
> 

Hi Paul,

To be honest, I have noticed the problem during the implementation of
AF_XDP feature for IDPF driver. In my scenario, I had 2 Tx queues:
 - regular LAN Tx queue
 - and XDP Tx queue
added to the same q_vector attached to the same NAPI, so those 2 Tx
queues were handled in the same NAPI poll loop.
Then, when I started a huge Tx zero-copy trafic using AF_XDP (on the XDP
queue), and, at the same time, tried to xmit a few packets using the second
(non-XDP) queue (e.g. with scapy), I was getting the Tx timeout on that regular
LAN Tx queue.
That is why I decided to upstream this fix. With disabled writebacks,
there is no chance to get the completion descriptor for the queue where
the traffic is much lighter.

I have never tried to reproduce the scenario described by Joshua
in his original patch ("unnecessary delays when traffic is light").

Thanks,
Michal


  reply	other threads:[~2023-12-13 13:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12 14:55 [Intel-wired-lan] [PATCH iwl-net] idpf: enable WB_ON_ITR Michal Kubiak
2023-12-12 14:55 ` Michal Kubiak
2023-12-12 16:50 ` [Intel-wired-lan] " Paul Menzel
2023-12-12 16:50   ` Paul Menzel
2023-12-13 13:23   ` Michal Kubiak [this message]
2023-12-13 13:23     ` Michal Kubiak
2023-12-13 13:51     ` Michal Kubiak
2023-12-13 13:51       ` Michal Kubiak
2023-12-13 22:22       ` Nguyen, Anthony L
2023-12-13 22:22         ` Nguyen, Anthony L
2023-12-13 23:06         ` Tony Nguyen
2023-12-13 23:06           ` Tony Nguyen
2023-12-15 17:27           ` Michal Kubiak
2023-12-15 17:27             ` Michal Kubiak
2023-12-14 12:59     ` Paul Menzel
2023-12-14 12:59       ` Paul Menzel
2023-12-15 17:32       ` Michal Kubiak
2023-12-15 17:32         ` Michal Kubiak
2023-12-15 18:01 ` Brett Creeley
2023-12-15 18:01   ` Brett Creeley
2023-12-15 19:04   ` [Intel-wired-lan] " Michal Kubiak
2023-12-15 19:04     ` Michal Kubiak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXmwR4s25afUbwz3@localhost.localdomain \
    --to=michal.kubiak@intel.com \
    --cc=alan.brady@intel.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=emil.s.tantilov@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=joshua.a.hay@intel.com \
    --cc=larysa.zaremba@intel.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=przemyslaw.kitszel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.