netdev - Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

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: <CALx6S34vso438+85ggvzkkCQBPRA7f6tHv1qtwVqq=tuxG=uJQ@mail.gmail.com>
Date:	Mon, 30 Nov 2015 13:48:36 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	"Singhai, Anjali" <anjali.singhai@...el.com>
Cc:	David Miller <davem@...emloft.net>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"jesse@...nel.org" <jesse@...nel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Patil, Kiran" <kiran.patil@...el.com>
Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Mon, Nov 30, 2015 at 1:42 PM, Singhai, Anjali
<anjali.singhai@...el.com> wrote:
>
>
> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Sunday, November 29, 2015 7:23 PM
> To: tom@...bertland.com
> Cc: Brandeburg, Jesse <jesse.brandeburg@...el.com>; Singhai, Anjali <anjali.singhai@...el.com>; jesse@...nel.org; netdev@...r.kernel.org; Patil, Kiran <kiran.patil@...el.com>
> Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
>
> From: Tom Herbert <tom@...bertland.com>
> Date: Tue, 24 Nov 2015 09:32:11 -0800
>
>>>
>>> FWIW, I've brought the issue to the attention of the architects here,
>>> and we will likely be able to make changes in this space.  Intel
>>> hardware (as demonstrated by your patches) already is able to deal
>>> with this de-ossification on transmit.  Receive is a whole different beast.
>>>
>> Please provide the specifics on why "Receive is a whole different
>> beast.". Generic receive checksum is already a subset of the
>> functionality that you must have implement to support the protocol
>> specific offloads. All the hardware needs to do is calculate the 1's
>> complement checksum of the packet and return the value on the to the
>> host with that packet. That's it. No parsing of headers, no worrying
>> about the pseudo header, no dealing with any encapsulation. Just do
>> the calculation, return the result to the host and the driver converts
>> this to CHECKSUM_COMPLETE. I find it very hard to believe that this is
>> any harder than specific support the next protocol du jour.
>
> The reason for receive being different than transmit is, on TX side driver can provide the meta data for where the checksum field is and what is the length that needs to be check summed to the HW on a per packet basis. On Rx the HW parser has to parse the packet to identify the tunnel type and based on that figure out the checksum locations and length in the packet, so definitely HW has to parse the packet and it can parse only based on next header type information or in case of udp tunnels based on udp port mapping to a particular protocol. I am not sure why you say it doesn't need to parse the packet, maybe I am miss- understanding something.  Although it's not difficult to reduce protocol ossification on the RX side but it is certainly different and particularly in case of udp-tunnels it needs the port to protocol mapping.
>
Please look at how CHECKSUM_COMPLETE interface works. Description is
in sk_buff.h or
http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf.

Thanks,
Tom
--
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