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/
On Thu, 19 Jul 2007 08:47:01 -0700 (PDT)
andrei radulescu-banu [off-list ref] wrote:
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.
quoted
[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.
No, VLAN is wrong to expect the CB to survive through layers. The CB is
a private scribble area that can be used by which ever piece of code currently
"owns" the skb. If data needs to be passed from layer to layer, it needs to
be done as separate fields in the skb itself. If A passes an skb to B, then
the CB can be changed by B (or things it calls) before it arrives at C.
andrei radulescu-banu wrote:
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.
No its not. Its only legal to use while something has ownership
of the skb. Between VLAN devices and real devices qdiscs are
free to use it.
quoted
[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.
No, we might want to put other data in the cb in the future.
VLAN should follow the rules instead.
andrei radulescu-banu wrote:
quoted
[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.
I think it would be valid to let a few packets slip through on the old
behaviour during changeover..or perhaps to drop them
entirely if that is required.
Turning off vlan hw-accel when the nic goes promisc is also going to
require driver changes, I believe, so
either way you have to do that work.
If tcpdump and/or bridging needs to disable the hw-accel, then it can
explicitly do so by some API. That is better than overloading
the promisc flag in my opinion. This is especially true since promisc
is not easily readable by user-space and things like tcpdump
cannot have full control of promisc (if a mac-vlan has the NIC in
promisc mode, for instance, then tcpdump can never disable it.)
Any comments on what is the expected behavior of 'tcpdump -i eth0.2' vs. 'tcpdump -i eth0'?
I would expect that you see tags with -i eth0, but not with -i eth0.2
That is the way it currently works with non-hw-accell VLANs (or it was
the last I checked).
Ben
--
Ben Greear [off-list ref]
Candela Technologies Inc http://www.candelatech.com