From: Ben Greear <greearb@candelatech.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
herbert@gondor.apana.org.au, david@davidcoulson.net,
kaber@trash.net, netdev@oss.sgi.com
Subject: Re: skb_checksum_help
Date: Tue, 25 Jan 2005 12:48:16 -0800 [thread overview]
Message-ID: <41F6B090.6020602@candelatech.com> (raw)
In-Reply-To: <20050125203607.GG31837@postel.suug.ch>
Thomas Graf wrote:
> * Thomas Graf <20050125143319.GF31837@postel.suug.ch> 2005-01-25 15:33
>
>>* David S. Miller <20050124194328.20a106de.davem@davemloft.net> 2005-01-24 19:43
>>
>>>On Tue, 25 Jan 2005 03:24:31 +0100
>>>Thomas Graf <tgraf@suug.ch> 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.
>
> NETIF_F_SG|NETIF_F_TSO:
> 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.
>
> NETIF_F_NO_CSUM:
> Avoid checksumming for vlan devices on loopback interfaces.
>
> NETIF_F_HIGHDMA|NETIF_F_FRAGLIST:
> Didn't find a reason why this would cause problems.
>
> NETIF_F_LLTX:
> vlan code accesses statistic counters so I think we can't
> inherit. It might be worth to make it clean though.
>
> NETIF_F_IP_CSUM|NETIF_F_HW_CSUM:
> 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@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2005-01-25 20:48 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <41F432BD.3000300@davidcoulson.net>
2005-01-24 0:32 ` skb_checksum_help Thomas Graf
2005-01-24 0:49 ` skb_checksum_help Patrick McHardy
2005-01-24 0:53 ` skb_checksum_help Thomas Graf
2005-01-24 1:31 ` skb_checksum_help Herbert Xu
2005-01-24 4:27 ` skb_checksum_help David S. Miller
2005-01-24 4:38 ` skb_checksum_help David S. Miller
2005-01-24 4:46 ` skb_checksum_help Patrick McHardy
2005-01-24 4:56 ` skb_checksum_help Herbert Xu
2005-01-24 5:07 ` skb_checksum_help Patrick McHardy
2005-01-24 12:22 ` skb_checksum_help Thomas Graf
2005-01-24 13:09 ` skb_checksum_help Patrick McHardy
2005-01-24 14:49 ` skb_checksum_help David Coulson
2005-01-24 12:16 ` skb_checksum_help Thomas Graf
2005-01-24 14:51 ` skb_checksum_help David Coulson
2005-01-24 15:15 ` skb_checksum_help Thomas Graf
2005-01-24 15:27 ` skb_checksum_help David Coulson
2005-01-24 22:54 ` skb_checksum_help Herbert Xu
2005-01-24 23:45 ` skb_checksum_help Thomas Graf
2005-01-25 0:07 ` skb_checksum_help Herbert Xu
2005-01-25 0:40 ` skb_checksum_help David S. Miller
2005-01-25 1:45 ` skb_checksum_help Thomas Graf
2005-01-25 1:48 ` skb_checksum_help Herbert Xu
2005-01-25 1:59 ` skb_checksum_help David Coulson
2005-01-25 2:07 ` skb_checksum_help Herbert Xu
2005-01-25 2:01 ` skb_checksum_help Thomas Graf
2005-01-25 2:03 ` skb_checksum_help David S. Miller
2005-01-25 2:24 ` skb_checksum_help Thomas Graf
2005-01-25 3:43 ` skb_checksum_help David S. Miller
2005-01-25 12:05 ` skb_checksum_help David Coulson
2005-01-25 14:33 ` skb_checksum_help Thomas Graf
2005-01-25 20:36 ` skb_checksum_help Thomas Graf
2005-01-25 20:48 ` Ben Greear [this message]
2005-01-25 21:15 ` skb_checksum_help Thomas Graf
2005-01-25 22:14 ` skb_checksum_help Ben Greear
2005-01-25 23:31 ` skb_checksum_help David S. Miller
2005-01-25 23:30 ` skb_checksum_help David S. Miller
2005-01-25 20:50 ` skb_checksum_help David S. Miller
2005-01-25 2:02 ` skb_checksum_help David S. Miller
2005-01-25 2:14 ` skb_checksum_help Herbert Xu
2005-01-25 11:23 ` skb_checksum_help Herbert Xu
2005-01-25 20:46 ` skb_checksum_help David S. Miller
2005-01-25 2:15 ` skb_checksum_help Patrick McHardy
2005-01-25 14:16 ` skb_checksum_help David Coulson
2005-01-24 1:31 ` skb_checksum_help David Coulson
2005-01-24 12:31 ` skb_checksum_help Thomas Graf
2005-01-24 14:25 ` skb_checksum_help David Coulson
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=41F6B090.6020602@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@davemloft.net \
--cc=david@davidcoulson.net \
--cc=herbert@gondor.apana.org.au \
--cc=kaber@trash.net \
--cc=netdev@oss.sgi.com \
--cc=tgraf@suug.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.