public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: "Greenman, Gregory" <gregory.greenman@intel.com>,
	Kalle Valo <kvalo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"Goodstein, Mordechay" <mordechay.goodstein@intel.com>,
	 "Coelho, Luciano" <luciano.coelho@intel.com>,
	"Sisodiya, Mukesh" <mukesh.sisodiya@intel.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] wifi: iwlwifi: Fix spurious packet drops with RSS
Date: Fri, 05 May 2023 08:40:16 +0200	[thread overview]
Message-ID: <f02a94a6cad2e87e0cfe9c8ca8eedc89753313ab.camel@sipsolutions.net> (raw)
In-Reply-To: <ZFPxkRKep27H74Su@sultan-box.localdomain>

On Thu, 2023-05-04 at 10:55 -0700, Sultan Alsawaf wrote:
> > 
> > So I assume you tested it now, and it works? Somehow I had been under
> > the impression we never got it to work back when...
> 
> Yep, I've been using this for about a year and have let it run through the
> original iperf3 reproducer I mentioned on bugzilla for hours with no stalls. My
> big git clones don't freeze anymore either. :)

Oh! OK, great.

> What I wasn't able to get working was the big reorder buffer cleanup that's made
> possible by using these firmware bits. The explicit queue sync can be removed
> easily, but there were further potential cleanups you had mentioned that I
> wasn't able to get working.

Fair enough.

> I hadn't submitted this patch until now because I was hoping to get the big
> cleanup done simultaneously but I got too busy until now. Since this small patch
> does fix the issue, my thought is that this could be merged and sent to stable,
> and with subsequent patches I can chip away at cleaning up the reorder buffer.

Sure, that makes sense.

> > > Johannes mentions that the 9000 series' firmware doesn't support these
> > > bits, so disable RSS on the 9000 series chipsets since they lack a
> > > mechanism to properly detect old and duplicated frames.
> > 
> > Indeed, I checked this again, I also somehow thought it was backported
> > to some versions but doesn't look like. We can either leave those old
> > ones broken (they only shipped with fewer cores anyway), or just disable
> > it as you did here, not sure. RSS is probably not as relevant with those
> > slower speeds anyway.
> 
> Agreed, I think it's worth disabling RSS on 9000 series to fix it there. If the
> RX queues are heavily backed up and incoming packets are not released fast
> enough due to a slow CPU, then I think the spurious drops could happen somewhat
> regularly on slow devices using 9000 series.
> 
> It's probably also difficult to judge the impact/frequency of these spurious
> drops in the wild due to TCP retries potentially masking them. The issue can be
> very noticeable when a lot of packets are spuriously dropped at once though, so
> I think it's certainly worth the tradeoff to disable RSS on the older chipsets.

:)

> Indeed, and removing the queue sync + timer are easy. Would you prefer I send
> additional patches for at least those cleanups before the fix itself can be
> considered for merging?
> 

No, you know, maybe this is easier since it's the smallest possible
change that fixes issues. Just have to see what Emmanuel says, he had
said he sees issues with this change.

johannes

      reply	other threads:[~2023-05-05  6:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230430001348.3552-1-sultan@kerneltoast.com>
2023-05-04 12:10 ` [PATCH] wifi: iwlwifi: Fix spurious packet drops with RSS Johannes Berg
2023-05-04 17:55   ` Sultan Alsawaf
2023-05-05  6:40     ` Johannes Berg [this message]

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=f02a94a6cad2e87e0cfe9c8ca8eedc89753313ab.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gregory.greenman@intel.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luciano.coelho@intel.com \
    --cc=mordechay.goodstein@intel.com \
    --cc=mukesh.sisodiya@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sultan@kerneltoast.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox