Thread (94 messages) 94 messages, 15 authors, 2015-12-09

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

From: Tom Herbert <hidden>
Date: 2015-11-30 21:48:37

On Mon, Nov 30, 2015 at 1:42 PM, Singhai, Anjali
[off-list ref] wrote:

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Sunday, November 29, 2015 7:23 PM
To: tom@herbertland.com
Cc: Brandeburg, Jesse <redacted>; Singhai, Anjali <redacted>; jesse@kernel.org; netdev@vger.kernel.org; Patil, Kiran <redacted>
Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

From: Tom Herbert <redacted>
Date: Tue, 24 Nov 2015 09:32:11 -0800
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help