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: Fri, 15 Dec 2023 18:32:02 +0100 [thread overview]
Message-ID: <ZXyNklin95kqbpMp@localhost.localdomain> (raw)
In-Reply-To: <f5b560ed-783d-49fe-ba51-c4f77e30c479@molgen.mpg.de>
On Thu, Dec 14, 2023 at 01:59:57PM +0100, Paul Menzel wrote:
> Lieber Michal,
>
>
> Am 13.12.23 um 14:23 schrieb Michal Kubiak:
> > On Tue, Dec 12, 2023 at 05:50:55PM +0100, Paul Menzel wrote:
>
> > > 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.
>
> Thanks.
Will be fixed in v2.
>
> > > > 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?
>
> […]
>
> > 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").
>
> Understood. Maybe you could add a summary of the above to the commit message
> or just copy and paste. I guess, it’s better than nothing. And thank you for
> upstreaming this.
>
>
> Kind regards,
>
> Paul
Right. I have to add some kdocs, so I will also extend that commit message in v2.
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: Fri, 15 Dec 2023 18:32:02 +0100 [thread overview]
Message-ID: <ZXyNklin95kqbpMp@localhost.localdomain> (raw)
In-Reply-To: <f5b560ed-783d-49fe-ba51-c4f77e30c479@molgen.mpg.de>
On Thu, Dec 14, 2023 at 01:59:57PM +0100, Paul Menzel wrote:
> Lieber Michal,
>
>
> Am 13.12.23 um 14:23 schrieb Michal Kubiak:
> > On Tue, Dec 12, 2023 at 05:50:55PM +0100, Paul Menzel wrote:
>
> > > 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.
>
> Thanks.
Will be fixed in v2.
>
> > > > 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?
>
> […]
>
> > 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").
>
> Understood. Maybe you could add a summary of the above to the commit message
> or just copy and paste. I guess, it’s better than nothing. And thank you for
> upstreaming this.
>
>
> Kind regards,
>
> Paul
Right. I have to add some kdocs, so I will also extend that commit message in v2.
Thanks,
Michal
next prev parent reply other threads:[~2023-12-15 17:32 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
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 [this message]
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=ZXyNklin95kqbpMp@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.