From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [net-next.git 2/7] stmmac: review barriers
Date: Wed, 03 Apr 2013 09:28:28 +0200 [thread overview]
Message-ID: <515BDA1C.8010503@st.com> (raw)
In-Reply-To: <1364973523.13853.4.camel@edumazet-glaptop>
On 4/3/2013 9:18 AM, Eric Dumazet wrote:
> On Wed, 2013-04-03 at 07:41 +0200, Giuseppe CAVALLARO wrote:
>> In all my tests performed on SH4 and ARM A9 platforms, I've never met problems
>> that can be fixed by using memory barriers. In the past there was some issues
>> on SMP ARM but fixed by reviewing xmit spinlock.
>>
>> Further barriers have been added in the commits too: 8e83989106562326bf
>>
>> This patch is to use the smp_wbm instead of wbm because the driver
>> runs on UP systems. Then, IMO it could make sense to only maintain the barriers
>> just in places where we touch the dma owner bits (that is the
>> only real critical path as we had seen and fixed in the commit:
>> eb0dc4bb2e22c04964d).
>>
>> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Cc: Deepak Sikri <deepak.sikri@st.com>
>> Cc: Shiraz Hashim <shiraz.hashim@st.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++------
>> 1 files changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 8b69e3b..c92dcbc 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -1797,15 +1797,13 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>> priv->tx_skbuff[entry] = NULL;
>> priv->hw->desc->prepare_tx_desc(desc, 0, len, csum_insertion,
>> priv->mode);
>> - wmb();
>> + smp_wmb();
>> priv->hw->desc->set_tx_owner(desc);
>
> This looks pretty bogus to me.
>
> If arch is UP, smp_wmb() is empty.
>
> So why are you using it ?
>
> Barrier here is not to protect the interaction with another cpu, but the
> NIC itself.
>
> If there is no need for barrier as you claim in changelog, don't add a
> fake smp_wmb().
>
ok I'll do it because I do not need any barrier when test on my UP and
SMP. Barriers were added for SPEAr but I have never seen problems
although I have not done too many tests on these platforms. I usually
run on other ST ARM box but, as rule of thumb, similar to some SPEAr
for CPU and MAC.
At any rate, if somebody aims to have them we will discuss in this
mailing list to understand why/where these have to be placed in the code
peppe
next prev parent reply other threads:[~2013-04-03 7:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 5:41 [net-next.git 1/7] stmmac: review napi gro support Giuseppe CAVALLARO
2013-04-03 5:41 ` [net-next.git 2/7] stmmac: review barriers Giuseppe CAVALLARO
2013-04-03 7:18 ` Eric Dumazet
2013-04-03 7:28 ` Giuseppe CAVALLARO [this message]
2013-04-03 8:51 ` Shiraz Hashim
2013-04-04 6:06 ` Giuseppe CAVALLARO
2013-04-04 15:08 ` Eric Dumazet
2013-04-03 14:02 ` Sergei Shtylyov
2013-04-03 5:41 ` [net-next.git 3/7] stmmac: review private structure fields Giuseppe CAVALLARO
2013-04-03 7:21 ` Eric Dumazet
2013-04-03 7:33 ` Giuseppe CAVALLARO
2013-04-03 16:09 ` Ben Hutchings
2013-04-04 6:11 ` Giuseppe CAVALLARO
2013-04-03 5:41 ` [net-next.git 4/7] stmmac: review driver documentation Giuseppe CAVALLARO
2013-04-03 5:41 ` [net-next.git 5/7] stmmac: improve/review and fix kernel-doc Giuseppe CAVALLARO
2013-04-03 5:41 ` [net-next.git 6/7] stmmac: code tidy-up Giuseppe CAVALLARO
2013-04-03 5:41 ` [net-next.git 7/7] stmmac: prefetch all dma_erx when use extend_desc Giuseppe CAVALLARO
2013-04-03 7:05 ` [net-next.git 1/7] stmmac: review napi gro support Eric Dumazet
2013-04-03 7:41 ` Giuseppe CAVALLARO
2013-04-03 13:39 ` Eric Dumazet
2013-04-04 6:16 ` Giuseppe CAVALLARO
2013-04-03 16:01 ` Ben Hutchings
2013-04-04 6:20 ` Giuseppe CAVALLARO
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=515BDA1C.8010503@st.com \
--to=peppe.cavallaro@st.com \
--cc=eric.dumazet@gmail.com \
--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).