All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, andy@greyhouse.net, fubar@us.ibm.com
Subject: Re: [PATCH net] bonding: fix arp monitoring with vlan slaves
Date: Sat, 03 Aug 2013 02:21:14 +0200	[thread overview]
Message-ID: <51FC4CFA.8010706@redhat.com> (raw)
In-Reply-To: <1375488223.4457.16.camel@edumazet-glaptop>

On 08/03/2013 02:03 AM, Eric Dumazet wrote:
> On Sat, 2013-08-03 at 01:29 +0200, Nikolay Aleksandrov wrote:
> 
>> 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 ?
> 
> Nope : LLTX devices are supposed to update their own dev->trans_start
> I added for these case a special comment as in :
> 
> drivers/net/ethernet/atheros/atl1e/atl1e_main.c:1883:   netdev->trans_start = jiffies; /* NETIF_F_LLTX driver :( */
> 
Ah, didn't know about that, so there could be an LLTX device with proper
trans_start if it updates it itself. Fair enough.

> trans_start is a txq property, and vlan devices have a single txq.
> 
> Updating the vlandev->trans_start or the vlantxq->trans_start would be a
> performance killer on MQ ethernet.
> 
Yeah, that part I got, that's why I said it explains a lot for me earlier :-)

> And frankly, as this trans_start is really seldom queried, it makes no
> sense to set it on fast path on the vlan device, if its properly done on
> the real device anyway.
> 
>> But what if the txqs get bound to a particular CPU, then the txq
>> trans_start is okay to be updated I suppose.
> 
> Not sure what you are saying. vlan xmit can be called from any cpus.
> 
Never mind, I didn't notice that the 8021q dev has a single txq as you said.

Thanks for taking the time to explain all this.

      reply	other threads:[~2013-08-03  0:21 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
2013-08-03  0:03       ` Eric Dumazet
2013-08-03  0:21         ` Nikolay Aleksandrov [this message]

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=51FC4CFA.8010706@redhat.com \
    --to=nikolay@redhat.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=fubar@us.ibm.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 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.