On Mon, Nov 30, 2015 at 1:42 PM, Singhai, Anjali <anjali.sing...@intel.com> wrote: > > > -----Original Message----- > From: David Miller [mailto:da...@davemloft.net] > Sent: Sunday, November 29, 2015 7:23 PM > To: t...@herbertland.com > Cc: Brandeburg, Jesse <jesse.brandeb...@intel.com>; Singhai, Anjali > <anjali.sing...@intel.com>; je...@kernel.org; netdev@vger.kernel.org; Patil, > Kiran <kiran.pa...@intel.com> > Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload > > From: Tom Herbert <t...@herbertland.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
