Page MenuHomeFreeBSD

ipv6: leave room for link headers in UDP
ClosedPublic

Authored by gallatin on Apr 15 2025, 5:38 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Sep 24, 7:29 AM
Unknown Object (File)
Sat, Sep 20, 9:01 PM
Unknown Object (File)
Thu, Sep 18, 11:22 PM
Unknown Object (File)
Sep 4 2025, 2:00 AM
Unknown Object (File)
Aug 29 2025, 12:07 AM
Unknown Object (File)
Aug 20 2025, 9:30 AM
Unknown Object (File)
Aug 12 2025, 1:36 AM
Unknown Object (File)
Aug 5 2025, 8:20 AM
Subscribers

Details

Summary

UDP over IPv6 was not leaving space for link headers, resulting in the ethernet header being placed in its own mbuf at the start of an mbuf chain sent to a NIC driver. This is inefficient, in terms of allocating 2x as many header mbufs as needed, and its also confusing for drivers which may expect to find ether/ip/l4 headers together in the same mbuf.

UDP over IPv4 already did this back in 2004 e6ccd70936186495ada83c2ee0e4cf74efa19811, so I've made a patch based on the IPv4 code.

I found this when putting together a patchset to implement UDP segmentation offload, and was confused why a driver was unable to properly offload segmentation for V6.

Diff Detail

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

Event Timeline

Only question I have is why the change from hlen -> sizeof(struct ip6_hdr)

I realize that either works but I would think it slightly more efficient to continue to use hlen since that (I presume without looking) is passed in and is the size of the ip header needed (6 or 4)... or maybe
its not and this is just a safe way to handle all cases?

This revision is now accepted and ready to land.Apr 15 2025, 6:20 PM

I will also stylistically prefer to remain hlen there. Or move the M_PREPEND(sizeof(struct)) above initialization of ulen, plen, hlen.

gallatin edited the summary of this revision. (Show Details)

Update to use hlen, which already holds the size of the ip6 hdr, as suggested by glebius

This revision now requires review to proceed.Apr 15 2025, 7:15 PM
This revision is now accepted and ready to land.Apr 15 2025, 7:26 PM
This revision was automatically updated to reflect the committed changes.