Thomas Graf wrote:
* Thomas Graf <20050125143319.GF31837@xxxxxxxxxxxxxx> 2005-01-25 15:33
* David S. Miller <20050124194328.20a106de.davem@xxxxxxxxxxxxx> 2005-01-24 19:43
On Tue, 25 Jan 2005 03:24:31 +0100
Thomas Graf <tgraf@xxxxxxx> wrote:
This of course explains it, didn't think of that. I thought it would
inherit the checksumming features.
It should, but only in very limited cases.
Because it is very chip dependant whether this works or not in
any case, we should probably create a special features flag for
this. Something like NETIF_F_VLAN_INHERIT_FEATURES.
Can't we just use NETIF_F_HW_VLAN_TX for this and inherit
NETIF_F_HW_CSUM | NETIF_F_IP_CSUM if it is set? I don't have any
specs at hand though.
Vlan devices don't inherit any features at the moment but it would make
sense to do so.
The normal vlan code seems to handle pskbs correctly, we don't gain
that much though. The big gain would be in the driver specific accel
code. I assume that the driver specific accel code is aware of
pskbs if the card can handle it but I haven't checked this yet.
Avoid checksumming for vlan devices on loopback interfaces.
Didn't find a reason why this would cause problems.
vlan code accesses statistic counters so I think we can't
inherit. It might be worth to make it clean though.
Assuming that the vlan accel code can always do the checksumming
if the card can do it.
I am leery of assuming these things for all drivers and all chipsets.
Maybe the driver itself could tell vlan code what sorts of flags it
can set? That takes the guess-work out, and each driver can add
the features support as it is verified to work. If any particular
hacks need to be used (ie, maybe chipset foo.rev-1a can't handle one
particular thing), then the VLAN code doesn't have to care.
new_dev->features = real_dev->vlan_features;
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com