On 4/5/06, Ben Greear [EMAIL PROTECTED] wrote:
Andrew Gallatin wrote:
I'm working on a driver for a 10GbE nic. I've just gotten to the point
where I
am verifying that 802.1q vlans work without hardware vlan offload. It
seems like
the netdev features flags (NETIF_F_SG|NETIF_F_IP_CSUM|NETIF_F_TSO) are not
being inherited by the vlan device. This leads to very high CPU
utilization,
especially when running applications which use sendfile, since it forces
data
copies.
I have verified this is the problem by printing the vlan device's features
from
the end of register_vlan_device(). If copy real_dev's features to new_dev,
then the performance problems disappear.
This seems logical to me. We might need some dynamic logic to deal
with vlans on top of bridge devices (I believe bridges adjust *their*
capabilities dynamically as devices are added to and removed from the bridge.)
So you are sayiing that you'd be willing to copy real_dev's
features flags when creating a vlan? Great! Unfortunately,
I know nothing about bridges. How would this dynamic logic
work?
We would also need to catch ethtool updates to
real_dev's features flags, so that ethtook -K would work as expected
on vlan devices. Or perhaps the dynamic logic to deal with
vlans on top of bridges would be able to deal with it.
This is especially confusing, since it appears ethtool's -K/-k commands
fall through to the real device. So it appears like the ethX.VLAN dev
has scatter-gather and checksum offload enabled, when actually it
does not.
Am I hitting a weird corner case in having a device which does
checksum/sg/tso and not vlan offload? Will this magically go away if I
implement some vlan hardware assist feature?
I doubt that will matter, but it's possible. DaveM and others know more about
the hardware assist path that I do...
Yes, I think you are correct, and it should not matter. i was just grasping
at straws.
Thank you,
Drew
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
