From: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>,
Alan Brady <alan.brady@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>,
intel-wired-lan@lists.osuosl.org,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH 1/1 iwl-net] idpf: disable local BH when scheduling napi for marker packets
Date: Wed, 14 Feb 2024 07:39:53 -0800 [thread overview]
Message-ID: <8fa3c29d-c7d3-421d-b567-e9bf997e6751@intel.com> (raw)
In-Reply-To: <dd7247e8-8a1a-4033-9c1e-c52339426b34@intel.com>
On 2/14/2024 6:54 AM, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Tue, 13 Feb 2024 14:16:47 +0100
>
>> From: Alan Brady <alan.brady@intel.com>
>> Date: Wed, 7 Feb 2024 16:42:43 -0800
>>
>>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>>
>>> Fix softirq's not being handled during napi_schedule() call when
>>> receiving marker packets for queue disable by disabling local bottom
>>> half.
>>
>> BTW, how exactly does this help?
>>
>> __napi_schedule() already disables interrupts (local_irq_save()).
>> napi_schedule_prep() only has READ_ONCE() and other atomic read/write
>> helpers.
>>
>> It's always been safe to call napi_schedule() with enabled BH, so I
>> don't really understand how this works.
It's been a while since I debugged this, I'll have to take a look again,
but its not so much about being safe as it is about making sure the
marker packets are received in those cases - like ifdown in the trace.
> This also needs to be dropped from the fixes queue until investigated.
> For now, it looks like a cheap hack (without the explanation how exactly
> it does help), not a proper fix.
It does fix the issue at hand. Looking at the kernel code I see multiple
examples of napi_schedule() being wrapped with local_bh_disable/enable,
so this appears to be a common (not uncommon?) technique.
Thanks,
Emil
>
> Thanks,
> Olek
WARNING: multiple messages have this Message-ID (diff)
From: "Tantilov, Emil S" <emil.s.tantilov@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>,
Alan Brady <alan.brady@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
<intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH 1/1 iwl-net] idpf: disable local BH when scheduling napi for marker packets
Date: Wed, 14 Feb 2024 07:39:53 -0800 [thread overview]
Message-ID: <8fa3c29d-c7d3-421d-b567-e9bf997e6751@intel.com> (raw)
In-Reply-To: <dd7247e8-8a1a-4033-9c1e-c52339426b34@intel.com>
On 2/14/2024 6:54 AM, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Tue, 13 Feb 2024 14:16:47 +0100
>
>> From: Alan Brady <alan.brady@intel.com>
>> Date: Wed, 7 Feb 2024 16:42:43 -0800
>>
>>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>>
>>> Fix softirq's not being handled during napi_schedule() call when
>>> receiving marker packets for queue disable by disabling local bottom
>>> half.
>>
>> BTW, how exactly does this help?
>>
>> __napi_schedule() already disables interrupts (local_irq_save()).
>> napi_schedule_prep() only has READ_ONCE() and other atomic read/write
>> helpers.
>>
>> It's always been safe to call napi_schedule() with enabled BH, so I
>> don't really understand how this works.
It's been a while since I debugged this, I'll have to take a look again,
but its not so much about being safe as it is about making sure the
marker packets are received in those cases - like ifdown in the trace.
> This also needs to be dropped from the fixes queue until investigated.
> For now, it looks like a cheap hack (without the explanation how exactly
> it does help), not a proper fix.
It does fix the issue at hand. Looking at the kernel code I see multiple
examples of napi_schedule() being wrapped with local_bh_disable/enable,
so this appears to be a common (not uncommon?) technique.
Thanks,
Emil
>
> Thanks,
> Olek
next prev parent reply other threads:[~2024-02-14 15:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 0:42 [Intel-wired-lan] [PATCH 1/1 iwl-net] idpf: disable local BH when scheduling napi for marker packets Alan Brady
2024-02-08 0:42 ` Alan Brady
2024-02-09 10:34 ` [Intel-wired-lan] " Simon Horman
2024-02-09 10:34 ` Simon Horman
2024-02-12 14:41 ` [Intel-wired-lan] " Alexander Lobakin
2024-02-12 14:41 ` Alexander Lobakin
2024-02-12 17:43 ` Tantilov, Emil S
2024-02-12 17:43 ` Tantilov, Emil S
2024-02-13 13:16 ` Alexander Lobakin
2024-02-13 13:16 ` Alexander Lobakin
2024-02-14 14:54 ` Alexander Lobakin
2024-02-14 14:54 ` Alexander Lobakin
2024-02-14 15:39 ` Tantilov, Emil S [this message]
2024-02-14 15:39 ` Tantilov, Emil S
2024-02-15 13:28 ` Alexander Lobakin
2024-02-15 13:28 ` Alexander Lobakin
2024-02-15 0:36 ` Jakub Kicinski
2024-02-15 0:36 ` Jakub Kicinski
2024-03-05 0:44 ` Singh, Krishneil K
2024-03-05 0:44 ` Singh, Krishneil K
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=8fa3c29d-c7d3-421d-b567-e9bf997e6751@intel.com \
--to=emil.s.tantilov@intel.com \
--cc=alan.brady@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
--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.