Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

[Edward Cree <ecree@solarflare.com>]

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