All inner checksum offload computation packets can't be fragmented.

[• hselasky]

Summary

This patch fixes checksum offloading for VXLAN.

MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

[bz]

sys/netinet6/ip6_output.c

1146

From a quick glance I believe this should do the right thing. I was wondering if you had to update the "TSO" case further up a well but I don't think so anymore on second thought.

[• hselasky]

Konstantin will also test this on Monday.

sys/netinet6/ip6_output.c

1146

I saw the same too, and concluded the TSO check is not affecting this piece of code.

[kib]

I am not sure I understand the logic behind this change.

This is only to placate the checksum offload engine, not because these packets cannot be fragmented, right? For instance, nothing prevents fragmentation on the route to destination.
Basically you mark some packets as 'do not send', if fragmentation conflicts with checksum offload.

Should the proper solution be to clear CSUM_INNER_* if stack decides that the packet should be fragmented?

[• hselasky]

I am not sure I understand the logic behind this change.

When you fragment a VXLAN packet, the inner payload gets split.

The full inner payload is needed in order to compute the inner checksums!

Clear?

--HPS

[bz]

In D29429#660048, @hselasky wrote:

I am not sure I understand the logic behind this change.

When you fragment a VXLAN packet, the inner payload gets split.

The full inner payload is needed in order to compute the inner checksums!

Clear?

I think what kib tries to say is: rather than not fragmenting (*) computing the checksum in software and clear the flags for the hw.

(*) fragmenting for not-offload is different from IP fragmentation. I have not checked what the IPv4 code does but the IPv6 code has had the above case already (e.g., when extension headers were added we do it in software and clear the flags); however we do for TSO what hseasky tries to achieve here, we tell the stack not to split the packet but pass it all in one piece to the offload engine which will then make <n> packets out of it. Makes the decision logic more complicated.

[kib]

In D29429#660072, @bz wrote:

In D29429#660048, @hselasky wrote:

I am not sure I understand the logic behind this change.

When you fragment a VXLAN packet, the inner payload gets split.

The full inner payload is needed in order to compute the inner checksums!

Clear?

I think what kib tries to say is: rather than not fragmenting (*) computing the checksum in software and clear the flags for the hw.

(*) fragmenting for not-offload is different from IP fragmentation. I have not checked what the IPv4 code does but the IPv6 code has had the above case already (e.g., when extension headers were added we do it in software and clear the flags); however we do for TSO what hseasky tries to achieve here, we tell the stack not to split the packet but pass it all in one piece to the offload engine which will then make <n> packets out of it. Makes the decision logic more complicated.

Right, otherwise we get the state were we cannot send the packet, if fragmentation is indeed required.

That said, why ip_output() decided to fragment the packet? Did you tracked it?

[• hselasky]

That said, why ip_output() decided to fragment the packet? Did you tracked it?

Yes, because ifconfig mtu was not used. So that both VXLAN and network interface used the same mtu.