All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Network protocol (IP,IPv6,...) and TC actions
       [not found] <20100411190845.GA18383@n7mm.org>
@ 2010-04-13 17:31 ` Jan Ceuleers
  2010-04-16 23:10   ` Network protocol (IP,IPv6,...) and TC actions (ACT_CSUM) Grégoire Baron
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Ceuleers @ 2010-04-13 17:31 UTC (permalink / raw)
  To: Grégoire Baron, netdev

Grégoire Baron wrote:
> As this .protocol member seems to be used at different moments when a
> packet is received, forwared or sent, and could contain something like
> ETH_P_8021Q which isn't a network protocol Id, can we say the struct
> sk_buff .protocol member is guaranteed to contain a network protocol Id
> in the struct sb_buff used in the TC action executions ?

Grégoire,

I suggest that you ask your question on the netdev mailing list (netdev@vger.kernel.org).

Cheers, Jan

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Network protocol (IP,IPv6,...) and TC actions (ACT_CSUM)
  2010-04-13 17:31 ` Network protocol (IP,IPv6,...) and TC actions Jan Ceuleers
@ 2010-04-16 23:10   ` Grégoire Baron
  0 siblings, 0 replies; 2+ messages in thread
From: Grégoire Baron @ 2010-04-16 23:10 UTC (permalink / raw)
  To: netdev; +Cc: Jan Ceuleers

Thanks Jan, for the suggestion.

Hi,

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
discover it.

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.

Best Regards,

Grégoire Baron

On Tue, Apr 13, 2010 at 07:31:07PM +0200, Jan Ceuleers wrote:
> Grégoire Baron wrote:
> > As this .protocol member seems to be used at different moments when a
> > packet is received, forwared or sent, and could contain something like
> > ETH_P_8021Q which isn't a network protocol Id, can we say the struct
> > sk_buff .protocol member is guaranteed to contain a network protocol Id
> > in the struct sb_buff used in the TC action executions ?
> 
> Grégoire,
> 
> I suggest that you ask your question on the netdev mailing list (netdev@vger.kernel.org).
> 
> Cheers, Jan

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-04-16 23:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20100411190845.GA18383@n7mm.org>
2010-04-13 17:31 ` Network protocol (IP,IPv6,...) and TC actions Jan Ceuleers
2010-04-16 23:10   ` Network protocol (IP,IPv6,...) and TC actions (ACT_CSUM) Grégoire Baron

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.