netdev - Re: Checksum offload queries

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]

Date:	Wed, 9 Dec 2015 14:42:06 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Edward Cree <ecree@...arflare.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: Checksum offload queries

On Wed, Dec 9, 2015 at 2:21 PM, Thomas Graf <tgraf@...g.ch> wrote:
> On 12/09/15 at 10:00am, Tom Herbert wrote:
>> On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree <ecree@...arflare.com> wrote:
>> > Which only pushes the problem onto when someone wants to nest
>> > encapsulations.  (I heard you like tunnels, so I put a tunnel in your
>> > tunnel so you can encapsulate while you encapsulate.)
>> > Or to put it another way, 2 isn't a number; the only numbers are 0, 1
>> > and infinity ;)
>> > Perhaps in practice 2 csums would be enough, for now.  But isn't the
>> > whole point of the brave new world of generic checksums that it should
>> > be future-proof?
>> >
>> If there is a need then we can add an arbitrary number. But no one has
>> proven there is a need, however we do have a real need for checksum
>> offload outside of the narrow uses of  NETIF_F_IP[V6]_CSUM.
>
> Need may be a strong word here but people have started doing nested
> tunneling by running container orchestration tools which use VXLAN
> to isolate containers inside of OpenStack virtual infrastructure which
> also creates virtual networks.
>
> I'm not saying it's sane or desirable but we will start seeing nested
> tunnels in the wild :-(

csum_start and csum_offset together occupy 32 bits. As demonstrated in
VXLAN RCO we can compress csum_start/csum_offset down to 8 bits which
means if necessary we could get up to four pairs in an sk_buff without
increasing its size. If you need more that four checksums to be
offloaded in single packet then I doubt getting checksum offload to
work is going to be your biggest problem.
--
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