All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <amwang@redhat.com>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	netdev@vger.kernel.org, herbert.xu@redhat.com,
	nhorman@redhat.com, davem@davemloft.net
Subject: Re: [Patch 2/2] mlx4: add dynamic LRO disable support
Date: Tue, 15 Jun 2010 16:53:27 +0800	[thread overview]
Message-ID: <4C173F87.7000704@redhat.com> (raw)
In-Reply-To: <20100609104950.GB2599@dhcp-lab-161.englab.brq.redhat.com>

On 06/09/10 18:49, Stanislaw Gruszka wrote:
> Hi Amerigo
>
> Sorry for being silent in this thread before.
>
> On Wed, Jun 09, 2010 at 05:23:35PM +0800, Cong Wang wrote:
>>>>> Is that flag test actually unsafe - and if so, how is testing num_lro
>>>>> any better?  Perhaps access to net_device::features should be wrapped
>>>>> with ACCESS_ONCE() to ensure that reads and writes are atomic.
>>>>>
>>>>
>>>> At least, I don't find there is any race with 'num_lro', thus
>>>> no lock is needed.
>>>
>>> In both cases there is a race condition but it is harmless so long as
>>> the read and the write are atomic.  There is a general assumption in
>>> networking code that this is the case for int and long.  Personally I
>>> would prefer to see this made explicit using ACCESS_ONCE(), but I don't
>>> see any specific problem in mlx4 (not that I'm familiar with this driver
>>> either).
>>
>> I read this email again.
>>
>> I think you misunderstood the race condition here. Even read and write
>> are atomic here, the race still exists. One can just set NETIF_F_LRO
>> asynchronously right before mlx4 check this flag in mlx4_en_process_rx_cq()
>> which doesn't take rtnl_lock.
>
> If so, it's better to stop device before modify LRO settings. I suggest
> something like that in mlx4_ethtool_op_set_flags:
>
> if (!!(data&  ETH_FLAG_LRO) != !!(dev->features&  NETIF_F_LRO)) {


What does this line mean? This is to ignore all other flags, right?

> 	/* Need to toggle LRO */
>
> 	if (netdev_running(dev)) {
>                 mutex_lock(&mdev->state_lock);
>                 mlx4_en_stop_port(dev);
>                 rc = mlx4_en_start_port(dev);
>                 if (rc)
>                         en_err(priv, "Failed to restart port\n");
> 	}
>
> 	dev->features ^= NETIF_F_LRO;
>
> 	if (netdev_running(dev))
>                 mutex_unlock(&mdev->state_lock);
> }
>

I don't think mdev->state_lock is used to protect dev->feature.
rtnl_lock is. I think switching to mlx4_ethtool_op_set_flags()
from the default one has already solved this.

Thanks!

  reply	other threads:[~2010-06-15  8:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03  3:38 [Patch 1/2] s2io: add dynamic LRO disable support Amerigo Wang
2010-06-03  3:39 ` [Patch 2/2] mlx4: " Amerigo Wang
2010-06-03 12:37   ` Ben Hutchings
2010-06-04  1:56     ` Cong Wang
2010-06-04 14:25       ` Ben Hutchings
2010-06-07  8:51         ` Cong Wang
2010-06-07 11:00           ` Stanislaw Gruszka
2010-06-07 13:15             ` Cong Wang
2010-06-09  9:23         ` Cong Wang
2010-06-09 10:49           ` Stanislaw Gruszka
2010-06-15  8:53             ` Cong Wang [this message]
2010-06-15  9:39               ` Stanislaw Gruszka
2010-06-17 10:54                 ` Cong Wang
2010-06-17 12:03                   ` Stanislaw Gruszka
2010-06-18  3:10                     ` Cong Wang
2010-06-03 13:38 ` [Patch 1/2] s2io: " Michal Schmidt
2010-06-05  8:53   ` Ramkrishna Vepa
2010-06-07  9:01     ` Cong Wang

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=4C173F87.7000704@redhat.com \
    --to=amwang@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=herbert.xu@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=sgruszka@redhat.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.