On Wed, Aug 31, 2016 at 4:31 AM, Yuval Mintz <yuval.mi...@qlogic.com> wrote: > One question I have regarding the feature, regarding the > partial offload compatible with ndo_features_check(). > > Consider the following example - > Let's assume my adapter is capable of doing outer-csum validation > for vxlan packets, but only if inner network protocol is IPv4, > while at the same time it's capable of doing gso offloading for any > vxlan-encapsulated packet.
When you say validation do you mean generating an outer checksum? If I recall ndo_features_check applies to Tx features not Rx features. I'll assume you mean Tx checksum offload and not validation. > In that case, I'll publish NETIF_F_GSO_UDP_TUNNEL_CSUM as > part of my offload capability [& encap capabilities], and in my driver's > implementation of ndo_features_check() I'd remove the feature in case > I'd find out SKB is vxlan whose inner network protocol is ipv6. Right. That sounds correct so far. > Is there a way I could have benefited from the partial offload in that > case? If I understand the feature correctly, if I were to publish > UDP_TUNNEL_CSUM under partial-gso, it would mean that stack would > peel the feature off until it would decide there's actual need for SW GSO, > thereby denying me the ability of utilizing the HW offload capability for > CSUM. > > Am I reading it wrong? Or does this trade-off exist? I think you may have that correct. Basically any feature you advertise as partially supporting via GSO_PARTIAL ends up being tied to the partial offload after that. Although from what I have seen the difference isn't really all that great between GSO_PARTIAL versus TSO. In many cases the stack generates MSS aligned frames anyway so all GSO_PARTIAL is really doing is unsharing the header and updating the header fields.
