Page MenuHomeFreeBSD

ipsec_accel: handle TSO if supported
Needs ReviewPublic

Authored by kib on Mar 5 2024, 11:21 AM.
Tags
None
Referenced Files
F86205476: D44222.diff
Sun, Jun 16, 11:50 PM
Unknown Object (File)
Mon, May 27, 8:16 AM
Unknown Object (File)
May 4 2024, 1:19 PM
Unknown Object (File)
Apr 29 2024, 8:53 AM
Unknown Object (File)
Apr 27 2024, 8:16 AM
Unknown Object (File)
Apr 26 2024, 3:55 AM
Unknown Object (File)
Apr 20 2024, 12:31 AM
Unknown Object (File)
Apr 14 2024, 5:46 PM

Details

Reviewers
rrs
rscheff
tuexen
Group Reviewers
transport
Summary
Allow for TSO to operate if network interface supports ipsec inline
offload and supports TSO over it.

Sponsored by:   NVIDIA networking

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Mar 5 2024, 11:21 AM

I guess we need also similar tweaks for the RACK stack...
Is there a description available, how this feature can be tested?
Which card is needed for testing? Is something like

mlx5_core0: <mlx5_core> mem 0x14082000000-0x14083ffffff at device 0.0 on pci1
mlx5: Mellanox Core driver 3.7.1 (November 2021)ugen0.1: <Synopsys XHCI root HUB> at usbus0

good enough?

The pasted lines do not provide the card model. Perhaps look at the pciconf -vl output for your mce0_core. It might work for Connect-X 6DX, but we practically tested Connect-X 7 only. CX-4 and 5, or smaller 6 do not support the offload.

The way to test is to config IPSEC with supported SA and enable offload, the watch for TSO. E.g. run iperf and see that large plain-text TCP packets seen on Tx, but are segmented and encrypted on wire.

In D44222#1008887, @kib wrote:

The pasted lines do not provide the card model. Perhaps look at the pciconf -vl output for your mce0_core. It might work for Connect-X 6DX, but we practically tested Connect-X 7 only. CX-4 and 5, or smaller 6 do not support the offload.

mlx5_core0@pci0:1:0:0:	class=0x020000 rev=0x00 hdr=0x00 vendor=0x15b3 device=0x1015 subvendor=0x15b3 subdevice=0x0003
    vendor     = 'Mellanox Technologies'
    device     = 'MT27710 Family [ConnectX-4 Lx]'
    class      = network
    subclass   = ethernet
mlx5_core1@pci0:1:0:1:	class=0x020000 rev=0x00 hdr=0x00 vendor=0x15b3 device=0x1015 subvendor=0x15b3 subdevice=0x0003
    vendor     = 'Mellanox Technologies'
    device     = 'MT27710 Family [ConnectX-4 Lx]'
    class      = network
    subclass   = ethernet

So unfortunately, I'm not able to test.

The way to test is to config IPSEC with supported SA and enable offload, the watch for TSO. E.g. run iperf and see that large plain-text TCP packets seen on Tx, but are segmented and encrypted on wire.

sys/netinet/tcp_output.c
547–548

Why are we getting rid of the IPSEC/IPSEC_SUPPORT ifdef's?

sys/netinet/tcp_output.c
547–548

The new condition to allow (to try enable) TSO on the flow is ipoptlen == ipsec_optlen. I tried to wrap it in the style of existing maze of #ifdef's, but this quickly appeared unmaintainable mess.

I decided that having these two local variables and the better code readability is the better approach to structure the code.

sys/netinet/tcp_output.c
547–548

So are you proposing to get rid of the #ifdefs in general and always compile IPSEC stuff in?

sys/netinet/tcp_output.c
547–548

Where do you see such proposal? Or even a move in this direction?

sys/netinet/tcp_output.c
547–548

I just wanted to make sure we keep the #ifdef stuff in general and just have an exception here. Thanks for clarifying.

Can't test it, but it looks OK.

This revision is now accepted and ready to land.Apr 1 2024, 6:04 PM
This revision now requires review to proceed.Mon, May 27, 4:06 AM