From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH v3 6/6] net: sh_eth: use NAPI
Date: Tue, 15 May 2012 13:47:44 +0900 [thread overview]
Message-ID: <4FB1DFF0.4040709@renesas.com> (raw)
In-Reply-To: <20120514.185034.399229364191924851.davem@davemloft.net>
2012/05/15 7:50, David Miller wrote:
> From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
> Date: Mon, 14 May 2012 15:47:24 +0900
>
>> This patch modifies the driver to use NAPI.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> I think your TX path is still extremely racey.
>
> No locks are held here, so you tell me what happens if we execute:
>
>> + /* check txdesc */
>> + txfree_num = sh_eth_txfree(ndev);
>> + if (txfree_num)
>
Thank you for your review.
In the sh_eth_txfree(), it check the tx descriptors. If the tx descriptor
is completed, it calls dev_kfree_skb_irq(), and it returns value 1 or more.
So, the sh_eth_poll() calls netif_wake_queue() if the dev_kfree_skb_irq() is
called.
> and at this exact moment the queue was in fact already awake and
> another thread of control transmits packets, and this action fills up
> the TX queue and stops the queue.
>
>> netif_wake_queue(ndev);
>
> This will erroneously wake the queue and trigger the debugging
> message in your TX function.
>
> You need strict synchronization between your TX queueing and TX
> liberation flows. So that queue stop and wake are only performed
> at the correct moment.
I will add netif_queue_stopped() in the sh_eth_poll().
> In fact, looking at how the mdp->lock is used in your TX routine, it
> seems to protect absolutely against nothing.
I wlll remove the mdp->lock in the sh_eth_start_xmit().
> Please read the TX flow of drivers/net/ethernet/broadcom/tg3.c to see
> how to do this correctly, and lock free, in a NAPI driver.
>
Thank you for your suggestion.
I will add netif_tx_lock/unlock before and after netif_wake_queue().
Best regards,
Yoshihiro Shimoda
next prev parent reply other threads:[~2012-05-15 4:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 6:47 [PATCH v3 6/6] net: sh_eth: use NAPI Shimoda, Yoshihiro
2012-05-14 22:50 ` David Miller
2012-05-15 4:47 ` Shimoda, Yoshihiro [this message]
2012-05-15 5:07 ` David Miller
2012-05-15 9:46 ` Shimoda, Yoshihiro
2012-05-15 13:43 ` Francois Romieu
2012-05-15 17:05 ` David Miller
2012-05-15 18:29 ` Francois Romieu
2012-05-16 2:24 ` Shimoda, Yoshihiro
2012-05-16 2:14 ` Shimoda, Yoshihiro
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=4FB1DFF0.4040709@renesas.com \
--to=yoshihiro.shimoda.uh@renesas.com \
--cc=davem@davemloft.net \
--cc=linux-sh@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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).