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
