On Mon, Nov 30, 2015 at 1:42 PM, Singhai, Anjali <[email protected]> wrote: > > > -----Original Message----- > From: David Miller [mailto:[email protected]] > Sent: Sunday, November 29, 2015 7:23 PM > To: [email protected] > Cc: Brandeburg, Jesse <[email protected]>; Singhai, Anjali > <[email protected]>; [email protected]; [email protected]; Patil, > Kiran <[email protected]> > Subject: Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload > > From: Tom Herbert <[email protected]> > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
