On 23/03/16 23:15, Alexander Duyck wrote: > Right, but the problem becomes how do you identify what tunnel wants > what. So for example we could theoretically have a UDP tunnel in a > UDP with checksum. How would we tell which one want to have the > checksum set and which one doesn't? The fact is we cannot. I think we can still handle that, assuming the device is only touching the innermost checksum (i.e. it's obeying csum_start/offset). We don't need flags to tell us what to fill in in GSO, we can work it all out: Make the series of per-protocol callbacks for GSO partial run inner- outwards, by using recursion at the head. Make each return a csum_edit value. Then for example: For IPv4 header, our checksum covers only our header, so we fold any edits into our own checksum, and pass csum_edit through unchanged. For UDP header, we look to see if the current checksum field is zero. If so, we leave it as zero, fold our edits into csum_edit and return the result. Otherwise, we fold our edits and csum_edit into our checksum field, and return zero. For GRE, we look at the checksumming bit in the GRE header, and behave similarly to UDP. Etcetera...
This should even be a worthwhile simplification of the non-nested case, because (if I understand correctly) it means GSO partial doesn't need the various gso_type flags we already have to specify tunnel type and checksum status; it just figures it out as it goes. If your device is touching other checksums as well, then of course you need to figure that out in your driver so you can cancel it out. But the device will only fiddle with the headers you tell it about (in your case I think that's outermost L3), not any others in the middle. So it should still all work, without the driver having to know about the nesting. > You are > looking too far ahead. We haven't gotten to tunnel in tunnel yet. IMHO, if our offloads are truly generic, tunnel in tunnel should be low- hanging fruit. (In principle, "VxLAN + Ethernet + IP + GRE" is just another encapsulation header, albeit a rather long one). Therefore, if it _isn't_ low-hanging fruit for us, we should suspect that we aren't generic. So even if it's not currently useful in itself, it's still a convenient canary. -Ed
