From: Heiner Kallweit <hkallweit1@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>, Jakub Kicinski <kuba@kernel.org>
Cc: David Miller <davem@davemloft.net>,
Realtek linux nic maintainers <nic_swsd@realtek.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] r8169: set IRQF_NO_THREAD if MSI(X) is enabled
Date: Mon, 2 Nov 2020 09:01:00 +0100 [thread overview]
Message-ID: <b8d6e0ec-7ccb-3d11-db0a-8f60676a6f8d@gmail.com> (raw)
In-Reply-To: <20201102000652.5i5o7ig56lymcjsv@skbuf>
On 02.11.2020 01:06, Vladimir Oltean wrote:
> On Sun, Nov 01, 2020 at 11:30:44PM +0100, Heiner Kallweit wrote:
>> We had to remove flag IRQF_NO_THREAD because it conflicts with shared
>> interrupts in case legacy interrupts are used. Following up on the
>> linked discussion set IRQF_NO_THREAD if MSI or MSI-X is used, because
>> both guarantee that interrupt won't be shared.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> Link: https://www.spinics.net/lists/netdev/msg695341.html
>
> I am not sure if this utilization of the Link: tag is valid. I think it
> has a well-defined meaning and maintainers use it to provide a link to
> the email where the patch was picked from:
> https://lkml.org/lkml/2011/4/6/421
>
Thanks for the link. There have been discussions whether to have the
change log of patches as part of the commit message or not, and as part
of this discussion how the Link tag can help. IIRC outcome was:
- Link tag can be used to point to a discussion elaborating on the
evolution of a patch series
- Link tag can be used to point to a discussion explaining the motivation
for a change
Having said that it's my understanding that this tag isn't to be used by
the maintainers only. However maintainers may see this differently.
>> ---
>> drivers/net/ethernet/realtek/r8169_main.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index 319399a03..4d6afaf7c 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -4690,6 +4690,7 @@ static int rtl_open(struct net_device *dev)
>> {
>> struct rtl8169_private *tp = netdev_priv(dev);
>> struct pci_dev *pdev = tp->pci_dev;
>> + unsigned long irqflags;
>> int retval = -ENOMEM;
>>
>> pm_runtime_get_sync(&pdev->dev);
>> @@ -4714,8 +4715,9 @@ static int rtl_open(struct net_device *dev)
>>
>> rtl_request_firmware(tp);
>>
>> + irqflags = pci_dev_msi_enabled(pdev) ? IRQF_NO_THREAD : IRQF_SHARED;
>> retval = request_irq(pci_irq_vector(pdev, 0), rtl8169_interrupt,
>> - IRQF_SHARED, dev->name, tp);
>> + irqflags, dev->name, tp);
>> if (retval < 0)
>> goto err_release_fw_2;
>>
>> --
>> 2.29.2
>>
>
> So all things considered, what do you want to achieve with this change?
> Is there other benefit with disabling force threading of the
> rtl8169_interrupt, or are you still looking to add back the
> napi_schedule_irqoff call?
>
As mentioned by Eric it doesn't make sense to make the minimal hard irq
handlers used with NAPI a thread. This more contributes to the problem
than to the solution. The change here reflects this. The actual discussion
would be how to make the NAPI processing a thread (instead softirq).
For using napi_schedule_irqoff we most likely need something like
if (pci_dev_msi_enabled(pdev))
napi_schedule_irqoff(napi);
else
napi_schedule(napi);
and I doubt that's worth it.
next prev parent reply other threads:[~2020-11-02 8:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-01 22:30 [PATCH net-next] r8169: set IRQF_NO_THREAD if MSI(X) is enabled Heiner Kallweit
2020-11-02 0:06 ` Vladimir Oltean
2020-11-02 8:01 ` Heiner Kallweit [this message]
2020-11-02 12:41 ` Vladimir Oltean
2020-11-02 15:18 ` Heiner Kallweit
2020-11-02 15:41 ` Vladimir Oltean
2020-11-04 1:37 ` Jakub Kicinski
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=b8d6e0ec-7ccb-3d11-db0a-8f60676a6f8d@gmail.com \
--to=hkallweit1@gmail.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=olteanv@gmail.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;
as well as URLs for NNTP newsgroup(s).