bridge: Add checksum offloading

[timo.voelker_fh-muenster.de]

Summary

Add transmission checksum offloading capabilities (IFCAP_TXCSUM, IFCAP_TXCSUM_IPV6, IFCAP_VLAN_HWCSUM) to the bridge and remove synchronization of IFCAP_TXCSUM and IFCAP_TXCSUM_IPV6 between member interfaces. For an outgoing packet with the checksum offloading flag set, the bridge now checks if the designated outgoing interface supports checksum offloading for the corresponding protocol. If not, it computes and inserts the checksum before passing the packet to the outgoing interface.

I see two use cases.

1. If the bridge is the source interface, the network stack won't compute the checksum in software anymore and, thus, can make use of the checksum offloading capability of the physical outgoing interface.
2. A virtual interface like epair can use checksum offloading more reliably. If the other epair end is in a bridge and the outgoing interface does not support checksum offloading for the chosen protocol, the bridge will take care of it.

Test Plan

If <IF> is your main network interface and <IP> the configured IP address on that interface. Add a bridge like this:

ifconfig bridge0 create
ifconfig <IF> inet <IP> -alias
ifconfig bridge0 addm <IF>
ifconfig bridge0 inet <IP>

The source interface of outgoing packet for the FreeBSD IP stack is now bridge0 (and not <IF> anymore).

Before this patch:
The FreeBSD IP stack stops using checksum offloading and computes checksums in software.

After this patch:
The FreeBSD IP stack keeps using checksum offloading.

[tuexen]

sys/net/if_bridge.c

2418

style.9: return (NULL);

2442

style.9: return (m);

2452

style.9: return (m);

2460

style.9: return (NULL);

2496

style.9: return (m);

2503

style.9: return (m);

2524

style.9: return (m);

[zlei]

Might be off-topic. I have ever had an idea, that introducing SOFT checksum offload to all soft interfaces. The upper stack will see this and hand over the calculating of the checksums to the interfaces. The soft interfaces may calculate the checksums when absolutely necessary, or let the edge physical interfaces do the stuff when the packets are leaving the host. Then we can benefits the hardware checksum, or we have better icache locality ( batch processing the mbufs ) when doing soft checksum.

What do you think ?

[glebius]

In D54948#1256749, @zlei wrote:

Might be off-topic. I have ever had an idea, that introducing SOFT checksum offload to all soft interfaces. The upper stack will see this and hand over the calculating of the checksums to the interfaces. The soft interfaces may calculate the checksums when absolutely necessary, or let the edge physical interfaces do the stuff when the packets are leaving the host. Then we can benefits the hardware checksum, or we have better icache locality ( batch processing the mbufs ) when doing soft checksum.

What do you think ?

Does this sound similar to https://wiki.freebsd.org/Networking/ChecksumOffloading ?

[afedorov]

Maybe someone remembers this project: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052226.html

[glebius]

In D54948#1257019, @afedorov wrote:

Maybe someone remembers this project: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052226.html

I do remember and thanks for the link! This is something that needs to be rebased and used for that.

[zlei]

In D54948#1256999, @glebius wrote:

In D54948#1256749, @zlei wrote:

Might be off-topic. I have ever had an idea, that introducing SOFT checksum offload to all soft interfaces. The upper stack will see this and hand over the calculating of the checksums to the interfaces. The soft interfaces may calculate the checksums when absolutely necessary, or let the edge physical interfaces do the stuff when the packets are leaving the host. Then we can benefits the hardware checksum, or we have better icache locality ( batch processing the mbufs ) when doing soft checksum.

What do you think ?

Does this sound similar to https://wiki.freebsd.org/Networking/ChecksumOffloading ?

Ah, I did not know the plan exists. Yes, my idea is almost the same with that.

[timo.voelker_fh-muenster.de]

Addressed @tuxen's style comments.

[timo.voelker_fh-muenster.de]

In D54948#1257019, @afedorov wrote:

Maybe someone remembers this project: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052226.html

Thanks for the link. Interesting work.

[timo.voelker_fh-muenster.de]

Allow enabling/disabling the new capabilities: IFCAP_TXCSUM, IFCAP_TXCSUM_IPV6, and IFCAP_VLAN_HWCSUM.

[kbowling]

Seems like progress to me. Would be good to get a pass from @ivy who did a lot in bridge lately. It would be a good idea to do present quick A/B test to make sure there are no unexpected perf issues. I don't think there is any reason to delay for GSO (unrelated) or a rework flippening offloads which can progress at its own pace.

sys/net/if_bridge.c

2420

something like this should eventually move to shared net code