From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH v3 6/6] net: sh_eth: use NAPI
Date: Wed, 16 May 2012 02:24:59 +0000 [thread overview]
Message-ID: <4FB30FFB.6090708@renesas.com> (raw)
In-Reply-To: <20120515182919.GA7157@electric-eye.fr.zoreil.com>
2012/05/16 3:29, Francois Romieu wrote:
> David Miller <davem@davemloft.net> :
>> From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
> [...]
>>> I will modify the code as the following. Is it correct?
>>>
>>> if (txfree_num) {
>>> netif_tx_lock(ndev);
>>> if (netif_queue_stopped(ndev))
>>> netif_wake_queue(ndev);
>>> netif_tx_unlock(ndev);
>>> }
>>
>> Yes, and then you don't need that private lock in the start_xmit()
>> method at all, since that method runs with the tx_lock held.
>
> I agree that the lock should go but:
> 1. something must be done to prevent sh_eth_txfree() being called
> at the same time from the xmit and poll handlers
> 2. while netif_tx locking above provides an implicit memory barrier,
> there won't be one in sh_eth_start_xmit once the lock is removed.
> mdp->dirty_tx changes may thus go unnoticed in sh_eth_start_xmit
>
Thank you for the review.
I checked tg3.c, and I found a patch to fix the race condition:
commit ID 1b2a72050 : [TG3]: Fix tx race condition
I will check the patch, and I will write such a patch for the sh_eth
driver later.
Best regards,
Yoshihiro Shimoda
WARNING: multiple messages have this Message-ID (diff)
From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH v3 6/6] net: sh_eth: use NAPI
Date: Wed, 16 May 2012 11:24:59 +0900 [thread overview]
Message-ID: <4FB30FFB.6090708@renesas.com> (raw)
In-Reply-To: <20120515182919.GA7157@electric-eye.fr.zoreil.com>
2012/05/16 3:29, Francois Romieu wrote:
> David Miller <davem@davemloft.net> :
>> From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
> [...]
>>> I will modify the code as the following. Is it correct?
>>>
>>> if (txfree_num) {
>>> netif_tx_lock(ndev);
>>> if (netif_queue_stopped(ndev))
>>> netif_wake_queue(ndev);
>>> netif_tx_unlock(ndev);
>>> }
>>
>> Yes, and then you don't need that private lock in the start_xmit()
>> method at all, since that method runs with the tx_lock held.
>
> I agree that the lock should go but:
> 1. something must be done to prevent sh_eth_txfree() being called
> at the same time from the xmit and poll handlers
> 2. while netif_tx locking above provides an implicit memory barrier,
> there won't be one in sh_eth_start_xmit once the lock is removed.
> mdp->dirty_tx changes may thus go unnoticed in sh_eth_start_xmit
>
Thank you for the review.
I checked tg3.c, and I found a patch to fix the race condition:
commit ID 1b2a72050 : [TG3]: Fix tx race condition
I will check the patch, and I will write such a patch for the sh_eth
driver later.
Best regards,
Yoshihiro Shimoda
next prev parent reply other threads:[~2012-05-16 2:24 UTC|newest]
Thread overview: 20+ 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 6:47 ` Shimoda, Yoshihiro
2012-05-14 22:50 ` David Miller
2012-05-14 22:50 ` David Miller
2012-05-15 4:47 ` Shimoda, Yoshihiro
2012-05-15 4:47 ` Shimoda, Yoshihiro
2012-05-15 5:07 ` David Miller
2012-05-15 5:07 ` David Miller
2012-05-15 9:46 ` Shimoda, Yoshihiro
2012-05-15 9:46 ` Shimoda, Yoshihiro
2012-05-15 13:43 ` Francois Romieu
2012-05-15 13:43 ` Francois Romieu
2012-05-15 17:05 ` David Miller
2012-05-15 17:05 ` David Miller
2012-05-15 18:29 ` Francois Romieu
2012-05-15 18:29 ` Francois Romieu
2012-05-16 2:24 ` Shimoda, Yoshihiro [this message]
2012-05-16 2:24 ` Shimoda, Yoshihiro
2012-05-16 2:14 ` 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=4FB30FFB.6090708@renesas.com \
--to=yoshihiro.shimoda.uh@renesas.com \
--cc=davem@davemloft.net \
--cc=linux-sh@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.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.