Thanks Jan, for the suggestion.
I will re-explain my situation.
I started to write a new TC action (ACT_CSUM) in order to be able to
force, specially when ACT_PEDIT is used, the update of common checksums:
* the IPv4 header checksum,
* the ICMP/IGMP and ICMPv6 checksums,
* the TCP/UDP checkusms,
* and why not, more ...
Also, the idea is to support directly IPv4 and IPv6.
The best user interface (via iproute2/tc) could to not ask the final
user to assume a specific network protocol, but let the action
With this aim, I would like to know if someone could confirm me the
struct sk_buff .protocol member is the good candidate to discover if I
have an IPv4, an IPv6 packet or any other network protocol, in the skb
got by the TC action code (supporting INGRESS and EGRESS).
Indeed, this struct sk_buff member could contain something like
ETH_P_8021Q, which isn't a network protocol Id ...
I think this kind of content isn't seen by the TC actions, which work
at the network level (even if their filter protocol flag accepts all).
If someone could confirm, thanks in advance.
By the same way, I've wondered if the struct sk_buff .len member could
be used to avoid to "discover" the network packet length in the TC
action code, especially in the case of IPv6 packets (and jumbogram ;-).
But, I think not, because it could be not the case in INGRESS TC action
execution, in my point of view, because the packet wasn't delivered to
the network protocol yet. Is my analysis right?
Thanks again for your help.