Page MenuHomeFreeBSD

ipsec_accel: handle TSO if supported
ClosedPublic

Authored by kib on Mar 5 2024, 11:21 AM.
Tags
None
Referenced Files
F102848446: D44222.id140820.diff
Sun, Nov 17, 11:12 PM
F102848426: D44222.id139129.diff
Sun, Nov 17, 11:12 PM
F102848405: D44222.id135400.diff
Sun, Nov 17, 11:11 PM
F102848400: D44222.id.diff
Sun, Nov 17, 11:11 PM
F102832101: D44222.diff
Sun, Nov 17, 6:17 PM
Unknown Object (File)
Sun, Nov 3, 12:56 PM
Unknown Object (File)
Mon, Oct 21, 11:27 AM
Unknown Object (File)
Mon, Oct 21, 11:27 AM

Details

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 Not Applicable
Unit
Tests Not Applicable

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
553–554

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

sys/netinet/tcp_output.c
553–554

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
553–554

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

sys/netinet/tcp_output.c
553–554

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

sys/netinet/tcp_output.c
553–554

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.May 27 2024, 4:06 AM
This revision was not accepted when it landed; it landed in state Needs Review.Jul 12 2024, 11:26 AM
This revision was automatically updated to reflect the committed changes.