Page MenuHomeFreeBSD

dpaa2: Setup interface caps on attach
ClosedPublic

Authored by dsl on Oct 29 2025, 2:06 PM.
Tags
None
Referenced Files
F138067881: D53436.diff
Fri, Nov 28, 3:20 PM
Unknown Object (File)
Thu, Nov 20, 5:23 PM
Unknown Object (File)
Thu, Nov 20, 5:22 PM
Unknown Object (File)
Thu, Nov 20, 5:21 PM
Unknown Object (File)
Thu, Nov 20, 5:13 PM
Unknown Object (File)
Mon, Nov 3, 5:18 AM
Unknown Object (File)
Mon, Nov 3, 5:18 AM
Unknown Object (File)
Mon, Nov 3, 1:25 AM
Subscribers

Details

Summary

I've recently discovered (to my surprise) that my jail on Honeycomb LX2 sends UDP and TCP packets with incorrect checksums over epair(4). Bisecting led me to 39d4094173f9 ("epair: add support for checksum offloading"). There's a "dpaa2_ni_setup_if_caps" function in dpaa2_ni.c which configures L3/L4 checksums HW offloading, but it wasn't called in my case during the boot process at all. However, toggling capabilities on the working dpni0 interface helped. I call "dpaa2_ni_setup_if_caps" as a part of the dpaa2_ni attach here.

Test Plan
  1. Run the latest CURRENT (e.g. 6fa18fe74461);
  2. $ drill freebsd.org;
  3. Observe proper address resolved;
  4. $ jexec <JAIL_ID> /bin/sh;
  5. $ drill freebsd.org;
  6. Observe a delay and a network error.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

dsl requested review of this revision.Oct 29 2025, 2:06 PM

This change seems trivial to me. I'd simply commit it if there are no objections.

Beware that this (L4), if I read it correctly, will also enable RX/TX checksum validation/generation for upper layer protocols for IPv6 packets even if that is not not advertised or enabled.

This revision is now accepted and ready to land.Thu, Nov 6, 9:17 PM
In D53436#1224250, @bz wrote:

Beware that this (L4), if I read it correctly, will also enable RX/TX checksum validation/generation for upper layer protocols for IPv6 packets even if that is not not advertised or enabled.

IFCAP_HWCSUM was set and enabled for the DPAA2 network interface in the past, but wasn't actually enabled in the hardware, i.e. it was broken before. If TCP/UDP checksums were calculated by whoever was sending frames before, they are re-calculated by the DPAA2 hardware for the whole frame by default. No changes here are expected.

@bz you meant IFCAP_HWCSUM_IPV6, didn't you? Hmm, I haven't tested it yet. Probably a good idea before committing changes.

This revision was automatically updated to reflect the committed changes.