mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: andrei radulescu-banu <iubica2@yahoo.com>
To: Patrick McHardy <kaber@trash.net>,
	Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>,
	linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: Linux, tcpdump and vlan
Date: Thu, 19 Jul 2007 08:47:01 -0700 (PDT)	[thread overview]
Message-ID: <123837.78916.qm@web56604.mail.re3.yahoo.com> (raw)

The consensus seems to be that skb's need to carry vlan accelerated tags in their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.

> [Patrick] On the TX path, it could simply use the CB, but this is actually
also wrong (for both macvlan and real devices) since qdiscs have
ownership of the skb in between, and at least netem *does* modify
the CB, breaking VLAN.

Thanks for pointing that out... It appears to me that qdisc/netem already breaks the vlan implementation, in the path 

vlan_dev_hwaccel_hard_start_xmit(): sets accelerated vlan tag in skb->cb, calls
dev_queue_xmit(): may pass skb to qdisc/netem, which may mangle skb->cb before calling
dev->hard_start_xmit(), resulting in a tx frame without its vlan tag.

So netem needs to look for hw accelerated vlan metadata and insert it in the skb... Don't see any other way around this. 

> [Patrick] Your suggestion of disabling VLAN acceleration in promiscuous
mode sounds like a reasonable solution until then ..

I was rather thinking of keeping hw vlan acceleration in promiscuous mode. Upon becoming promisc, the driver will be changed to disable vlan filters - it will reenable them when leaving promisc mode.

My 2 cents on vlan hw acceleration: it does not save much in computing cycles, if software is written carefully. It is vlan filtering that saves computing time.

> [Ben] I think a better method would be to allow disabling VLAN HW accel for a NIC with ethtool.

This requires changes to ethtool and e1000 driver, +other drivers. It is a handy thing to have. I don't view it as a solution to tcpdump - or to the vlan bridging problem. One concern: if we're switching hw accel mode on the fly, we need to carefully protect tx frames that are just about going out and have already been set up for the opposite mode.

Any comments on what is the expected behavior of 'tcpdump -i eth0.2' vs. 'tcpdump -i eth0'?

Andrei Radulescu-Banu
Brix Networks





       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

             reply	other threads:[~2007-07-19 15:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19 15:47 andrei radulescu-banu [this message]
2007-07-19 16:21 ` Stephen Hemminger
2007-07-19 16:33 ` Patrick McHardy
2007-07-19 16:47 ` Ben Greear
  -- strict thread matches above, loose matches on Subject: below --
2007-07-19 21:38 andrei radulescu-banu
2007-07-19 23:38 ` Ben Greear
2007-07-20 20:19   ` Krzysztof Halasa
2007-07-19 18:20 andrei radulescu-banu
2007-07-19 19:28 ` Stephen Hemminger
2007-07-19 17:46 andrei radulescu-banu
2007-07-19 16:02 andrei radulescu-banu
2007-07-20 19:58 ` Krzysztof Halasa
2007-07-20 20:34   ` Ben Greear
2007-07-21 11:32     ` Krzysztof Halasa
2007-07-21 17:57       ` Ben Greear
2007-07-21 21:15         ` Krzysztof Halasa
2007-07-18 19:34 andrei radulescu-banu
2007-07-18 22:57 ` Patrick McHardy
2007-07-18 23:22   ` Ben Greear
2007-07-18 23:34     ` Patrick McHardy
2007-07-19  0:01       ` Ben Greear
2007-07-19  0:19         ` Patrick McHardy
2007-07-19 13:28   ` Krzysztof Halasa
2007-07-19 13:41     ` Stephen Hemminger
2007-07-19 14:00       ` Patrick McHardy
2007-07-19 14:23       ` Krzysztof Halasa
2007-07-19 15:00         ` Stephen Hemminger
2007-07-19 15:45           ` Krzysztof Halasa
2007-07-19 15:20         ` Stephen Hemminger
2007-07-20 10:50 ` Florian Lohoff

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=123837.78916.qm@web56604.mail.re3.yahoo.com \
    --to=iubica2@yahoo.com \
    --cc=kaber@trash.net \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.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

all inboxes | Powered by JetHome®