On Tue Sep 8, 2026 at 2:52 AM EDT, Tariq Toukan wrote: > From: Cosmin Ratiu <[email protected]> > > Add PSP conformance tests using the same gro helper binary as other gro > tests , but in --psp mode. SPIs are procured by psp_gro.py from a real > PSP device and handed off to the gro sender & receiver. The sender > crafts and encrypts packets in software, the receiver relies fully on > the HW to decrypt, decapsulate and do HW GRO. > > Because the NIC decrypts and decapsulates before the frames reach the > receiver AF_PACKET tap, the gro receiver sees the plain frames and the > assertions remain exactly the same as other gro tests. > > So these tests verify, at length, that the device does PSP HW-GRO the > same way as plain TCP. > > Additional PSP-specific tests are defined to check that GRO doesn't > merge packets across PSP versions, SPIs, encryption-status, etc. > > Some gro tests are not included because they don't work: > - ip_csum: the checksum is recomputed by psp_dev_rcv().
psp_dev_rcv() isn't on the hw gro path for mlx5, right? > - tcp_csum: packets are marked with CHECKSUM_UNNECESSARY. this also seems strange to me as the hw gro engine and its decision to coalesce two packets sits upstream of this skb->ip_summed determination in the driver, right? > - ip_frag4/ip_frag6: PSP is incompatible with IP fragmentation. > - IPv6 extension header tests: PSP doesn't deal with IPv6 ext headers. > > Signed-off-by: Cosmin Ratiu <[email protected]> > Reviewed-by: Dragos Tatulea <[email protected]> > Signed-off-by: Tariq Toukan <[email protected]> > --- ... > + > +@ksft_variants(_ip_variants()) > +def test_psp_ver_diff(cfg, protocol): > + """Frames from two different PSP versions must not coalesce.""" > + init_psp_dev(cfg) > + if len(cfg.psp_info['psp-versions-cap']) < 2: nit: what the above checks is slightly different than what the _run() below uses, e.g. dev supports versions 0 and 2. > + raise KsftSkipEx("Device supports a single PSP version") > + > + _run(cfg, "psp_ver_diff", protocol, [0, 1]) > + couple of minor comments: Reviewed-by: Daniel Zahka <[email protected]>
