netdev - Re: [PATCH v3 net-next] net-gro: Prepare GRO stack for the upcoming tunneling support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPshTCj-N6d0astJAQZa-qqCCgdcidbjsNLCZcydsw8EAH1hsw@mail.gmail.com>
Date:	Fri, 13 Dec 2013 07:48:18 +0800
From:	Jerry Chu <hkchu@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Eric Dumazet <edumazet@...gle.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Ranjit Manomohan <ranjitm@...gle.com>
Subject: Re: [PATCH v3 net-next] net-gro: Prepare GRO stack for the upcoming
 tunneling support

On Fri, Dec 13, 2013 at 2:48 AM, David Miller <davem@...emloft.net> wrote:
> From: "H.K. Jerry Chu" <hkchu@...gle.com>
> Date: Wed, 11 Dec 2013 20:53:45 -0800
>
>> From: Jerry Chu <hkchu@...gle.com>
>>
>> This patch modifies the GRO stack to avoid the use of "network_header"
>> and associated macros like ip_hdr() and ipv6_hdr() in order to allow
>> an arbitary number of IP hdrs (v4 or v6) to be used in the
>> encapsulation chain. This lays the foundation for various IP
>> tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later.
>>
>> With this patch, the GRO stack traversing now is mostly based on
>> skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
>> skb->network_header). As a result all but the top layer (i.e., the
>> the transport layer) must have hdrs of the same length in order for
>> a pkt to be considered for aggregation. Therefore when adding a new
>> encap layer (e.g., for tunneling), one must check and skip flows
>> (e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a
>> different hdr length.
>>
>> Note that unlike the network header, the transport header can and
>> will continue to be set by the GRO code since there will be at
>> most one "transport layer" in the encap chain.
>>
>> Signed-off-by: H.K. Jerry Chu <hkchu@...gle.com>
>> Suggested-by: Eric Dumazet <edumazet@...gle.com>
>> Reviewed-by: Eric Dumazet <edumazet@...gle.com>
>
> Applied, thanks.

Thanks, David. I will submit a patch for GRE soon to demonstrate
just how easy it is to add tunneling support to GRO after the assumption
of only one IP hdr in the encap chain is removed. (I already have the
code but it doesn't support the CSUM flag. I'm thinking adding it
plus csum offload support before submitting the patch.)

Best,

Jerry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html