From: Jay Vosburgh <fubar@us.ibm.com>
To: Nikolay Aleksandrov <nikolay@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, andy@greyhouse.net
Subject: Re: [PATCH net] bonding: fix arp monitoring with vlan slaves
Date: Fri, 02 Aug 2013 16:59:07 -0700 [thread overview]
Message-ID: <13712.1375487947@death.nxdomain> (raw)
In-Reply-To: <51FC40E5.6050809@redhat.com>
Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>On 08/03/2013 01:17 AM, Eric Dumazet wrote:
>> On Fri, 2013-08-02 at 15:32 -0700, David Miller wrote:
>>
>>> Handling this specially in bonding isn't really ideal.
>>>
>>> Please either hide this detail in dev_trans_start(), or (preferrably)
>>> have vlan_dev_hard_start_xmit() set the trans_start timestamp
>>> properly thus making this just work for everything.
>>
>> vlan is LLTX, so setting the timestamp would incur false sharing on
>> multiqueue.
>>
>Yeah, this statement actually explains a lot for me, thanks :-)
>I knew it was because of the LLTX, but I was wondering about the possible
>reasons for the xmit_lock_owner check.
>So basically the arp monitoring (or any dev_trans_start code) won't work
>with LLTX devices because they don't get their trans_start updated (not the
>txq trans_start nor the dev->trans_start), is this correct ?
I think what Eric means is that it'll be a performance problem,
because the cache line with the trans_start field will be thrashed
between CPUs as updates compete with each other or inspection from
dev_trans_start. I suspect it will work from a functional point of view
(unless I'm missing something).
As a practical matter, it looks like bonding is at present the
only caller of dev_trans_start that passes either (a) a VLAN device, or
(b) a device other than itself (most drivers seem to use it for transmit
timeout detection on their own device).
Having software devices set trans_start seems unnecessary
(bonding doesn't set it, either), since they'll generally have a
hardware device underneath with a real trans_start value. It might be
hard to hunt down for tun, though.
>But what if the txqs get bound to a particular CPU, then the txq
>trans_start is okay to be updated I suppose.
>
>Nik
>> But it's true we need a helper, because many callers do
>>
>> if (dev->priv_flags & IFF_802_1Q_VLAN)
>> dev = vlan_dev_real_dev(dev);
>>
>> or the slighly better
>>
>> if (is_vlan_dev(dev))
>> dev = vlan_dev_real_dev(dev);
For just the bonding dev_trans_start() for a VLAN case, one of
the above in dev_trans_start() ought to be sufficient.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2013-08-02 23:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-02 16:41 [PATCH net] bonding: fix arp monitoring with vlan slaves Nikolay Aleksandrov
2013-08-02 22:32 ` David Miller
2013-08-02 22:40 ` Nikolay Aleksandrov
2013-08-02 23:17 ` Eric Dumazet
2013-08-02 23:29 ` Nikolay Aleksandrov
2013-08-02 23:59 ` Jay Vosburgh [this message]
2013-08-03 0:03 ` Eric Dumazet
2013-08-03 0:21 ` Nikolay Aleksandrov
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=13712.1375487947@death.nxdomain \
--to=fubar@us.ibm.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@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.