While offloading header modifications to TC, OVS is using {TCA_PEDIT} + {TCA_CSUM} combination as that it the only way to represent header rewrite.  However, {TCA_CSUM} is unable to calculate L4 checksums for IP fragments.

Normal OVS datapath is able to keep track of required checksum updates because it updates them at the same time with header re-writes, so it knows exactly what changes and can adjust the checksum incrementally by subtracting old bytes and adding new ones.  {TCA_CSUM} doesn't know what was changed by {TCA_PEDIT} and hence it can't do incremental changes.  And IP fragments do not contain the full data in order to recalculate L4 checksums from scratch.

L4 checksums (TCP, UDP) also contain L3 pseudo-header, so changes in L3 layer that contribute to the pseudo-header should not be offloaded either.

In case IP fragments will go through {TCA_PEDIT} + {TCA_CSUM} in TC, they will end up with incorrect L4 checksums after re-assembling on the other end.

What OVS should do if there is an action that requires L4 checksum re-calculation (modification of the relevant L3 or L4 header fields):

1. Un-widcard packet fragmentation bits in the mask.
2. If the packet is an IP fragment (first or later), do not install this flow to TC.

It is possible and even likely that hardware NICs will actually adjust checksums on the fly while executing header modifications, but our primary API is tc-flower and it doesn't support that and we can't actually know how the particular driver/hardware handles this situation.  And if the flow will not be offloaded to the hardware for any reason we will have broken logic in TC.