From: Eric Dumazet <eric.dumazet@gmail•com>
To: Jose Abreu <Jose.Abreu@synopsys•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
Joao Pinto <Joao.Pinto@synopsys•com>
Subject: Re: stmmac: Race in coalesce timer and NAPI
Date: Fri, 21 Sep 2018 06:54:10 -0700 [thread overview]
Message-ID: <109edd5e-15d2-e89a-9331-a63798eb292b@gmail.com> (raw)
In-Reply-To: <dd4b67f1-5ce7-22e2-8fe5-8925ec016386@synopsys.com>
On 09/21/2018 02:19 AM, Jose Abreu wrote:
> Hello,
>
> I'm getting a race in stmmac coalesce timer and the
> napi_schedule() interrupt and I'm asking for advice. Currently,
> we are scheduling NAPI in coalesce timer but this leads to
> stmmac_tx_clean() deadlock because this function tries to acquire
> queue lock.
This is strange. Which lock are you talking about ?
The napi_schedule() stuff should be enough to protect your use case.
>
> I find that this is not expected because only one instance of
> NAPI should run at same time so I was wondering if it is possible
> that xmit() callback is causing the deadlock ?
>
> BTW, this is solved by:
> - Directly call stmmac_tx_clean() in timer function AND
> - Use netif_tx_trylock() in stmmac_tx_clean(). Then, if queue
> is already locked we re-arm coalesce timer or reschedule NAPI.
>
> This is easily reproducible in an ARM board with 8 core running
> at 100MHz each.
>
> Thanks and Best Regards,
> Jose Miguel Abreu
>
It looks to me stmmac_napi_poll() should not apply/consume any budget for TX completion.
The budget for a NAPI poll shared by RX and TX is really only for the RX side.
netpoll will specificall call the poll() with budget==0 to only drain TX
prev parent reply other threads:[~2018-09-21 19:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 9:19 stmmac: Race in coalesce timer and NAPI Jose Abreu
2018-09-21 13:54 ` Eric Dumazet [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=109edd5e-15d2-e89a-9331-a63798eb292b@gmail.com \
--to=eric.dumazet@gmail$(echo .)com \
--cc=Joao.Pinto@synopsys$(echo .)com \
--cc=Jose.Abreu@synopsys$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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