On Fri, Dec 4, 2015, at 21:43, Tom Herbert wrote: > On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > Hi Dave, > > > > On Fri, Dec 4, 2015, at 21:06, David Miller wrote: > >> From: Hannes Frederic Sowa <han...@stressinduktion.org> > >> Date: Fri, 04 Dec 2015 20:59:05 +0100 > >> > >> > Yes, I agree, I am totally with you here. If generic offloading can be > >> > realized by NICs I am totally with you that this should be the way to > >> > go. I don't see that coming in the next (small number of) years, so I > >> > don't see a reason to stop this patchset. > >> > >> If I just apply this and say "yeah ok", the message is completely lost > >> and your prediction about "small number of years" indeed will occur. > >> > >> However if I push back hard on this, as I will, then the message has > >> some chance of seeping back to the people designing these chips. > >> > >> So that's what I'm going to do, like it or not. > >> > >> Or can someone convince me that someone who understand this stuff > >> is telling the hardware guys to universally put 2's complement > >> checksums into the descriptors? > >> > >> Who is doing that at each and every prominent ethernet hardware > >> verndor? > >> > >> Who? > >> > >> If I get silence, or some vague non-specific response, then I'm going > >> to hold my ground and keep pushing back on this stuff. > > > > This is not only about 1's checksumming but also about TSO (and to some > > smaller degree about RSS, as I tried to explain): if we attach a geneve > > header in front of a skb we expect the hardware to recognize it and > > duplicate it while doing the hardware segmentation. The hardware can > > only do so if it is in knowledge of the specific port (in this case UDP > > port used for geneve) which is in use for this particular tunneling > > transport protocol. We currently cannot describe this in a generic way, > > thus this patchset. (Please correct me if I am wrong!) > > > Yes, you are wrong. Port numbers are not used in transmit path to > signal offload. To perform TSO on UDP encapsulated packets the skb is > marked with SKB_GSO_UDP_TUNNEL or SKB_GSO_UDP_TUNNEL_CSUM and > SKB_GSO_TCP, etc. The driver can use information along with the > offsets of the inner and outer headers in the packet to set up the > operation in the device. Some devices only support TSO for VXLAN, but > regardless SKB_GSO_UDP_TUNNEL is generic for all known UDP > encapsulations. Protocol specific offload is not needed. Please start > looking at > http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf > and the kernel code to see how things _actually_ work.
I am sorry. Of course we have _inner_ header pointers and the corresponding gso_types in skb_shinfo to signal that already. Probably I got confused by some driver sources and commit descriptions I looked into lately. Thanks for the correction! :) Bye, Hannes -- 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