ip: improve deferred computation of checksums

[timo.voelker_fh-muenster.de]

Summary

This patch adds the same functionality for IPv4 as D51475 did for SCTP/TCP/UDP.

When the IP implementation sends a packet, it does not compute the corresponding checksum but defers that. It will determine whether the network interface selected for the packet has the requested capability and computes the checksum in software, if the selected network interface does not have the requested capability.
Do this not only for packets being sent by the local IP stack, but also when forwarding packets. Furthermore, when such packets are delivered to a local IP stack, do not compute or validate the checksum, since such packets have never been on the wire. This allows to support checksum offloading also in the case of local virtual machines or jails. Support for epair interfaces will be added in a separate commit.

[tuexen]

sys/netinet/ip_fastfwd.c

532

Why did you move this block under a condition?

[timo.voelker_fh-muenster.de]

sys/netinet/ip_fastfwd.c

532

I moved this block in the

if (ip_len <= nh->nh_mtu)

block, because it seems relevant only if the packet is not too large. If it is too large, the packet is either dropped or it is fragmented by calling ip_fragment(), which computes the checksum in software, independent of the interface's capabilities.

[tuexen]

sys/netinet/ip_fastfwd.c

532

Isn't that a generic change with no functional change intended? How is it related to improving the deferred computation of the IPv4 header checksum? Would it make sense to separate out this change?

[pouria]

sys/netinet/ip_fastfwd.c

532

IMHO, it should be separated into another revision. Other than that, it looks fine, but I haven't tested it yet.

[timo.voelker_fh-muenster.de]

To address @tuexen's and @p.mousavizadeh_protonmail.com's comments, I restrict the code changes in this review to the changes required to process incoming packets with IP checksum offloading and leave code improvements for another review.

[pouria]

sys/netinet/ip_input.c

526

I'm struggling to find a scenario where this condition is true.
Can you share some test cases or examples that would trigger a match for this line?
I'd like to better understand when the problem you're trying to solve arises.

[timo.voelker_fh-muenster.de]

sys/netinet/ip_input.c

526

Currently, I expect this condition will never be true. The idea is to extend the usage of checksum offloading with virtual interfaces like epair or tap.

epair already offers checksum offloading for TCP and UDP. For an outgoing packet, epair in fact does nothing but preserve the mbuf flags, which indicate that the packet still needs a valid checksum. The idea is to keep these flags until the packet leaves the host via an interface that computes and inserts the checksum in hardware.

If the packet is for the host, it never leaves the host but gets in the input path. The changes in D51475 were necessary to accept such a packet where the mbuf flag for SCTP, TCP, or UDP is set even though the corresponding checksum is still incorrect. This change here is necessary to accept such a packet if the mbuf flag for IP (i.e., CSUM_IP) is set even though the IP header checksum is still incorrect.

epair can be extended by checksum offloading for IP simply by adding CSUM_IP | in this line:

https://cgit.freebsd.org/src/tree/sys/net/if_epair.c#n447