Page MenuHomeFreeBSD

net80211: document the vap / device transmit paths, fragment node references
ClosedPublic

Authored by adrian on Apr 10 2025, 8:36 PM.
Referenced Files
F121926370: D49765.id155031.diff
Mon, Jun 30, 5:33 PM
Unknown Object (File)
Sat, Jun 28, 8:32 AM
Unknown Object (File)
Fri, Jun 27, 10:59 PM
Unknown Object (File)
Thu, Jun 26, 5:34 PM
Unknown Object (File)
Wed, Jun 18, 2:29 PM
Unknown Object (File)
Thu, Jun 12, 3:55 PM
Unknown Object (File)
Mon, Jun 9, 10:30 PM
Unknown Object (File)
Wed, Jun 4, 5:03 PM

Details

Summary
  • Document what the VAP and device transmit paths do. Take care to note down the 802.11 fragment handling and node references.
  • Almost none of the drivers (save ath(4), which I fixed a long time ago) implement 802.11 fragments after the big VAP rework done years and years ago. A few others announce support (mwl, ral, uath, wpi) but I haven't validated them. I'll be doing that as part of this work.
  • Add some comments in ieee80211_fragment() around how fragment node references work.

Diff Detail

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

Event Timeline

"Almost none of the drivers (save ath(4), which I fixed a long time ago) implement 802.11 fragments after the big VAP rework done years and years ago. "

Some drivers just say "let me do this in firmware... can you please turn it off?"

I have to validate those bits too soon along with other parts.

In D49765#1135092, @bz wrote:

"Almost none of the drivers (save ath(4), which I fixed a long time ago) implement 802.11 fragments after the big VAP rework done years and years ago. "

Some drivers just say "let me do this in firmware... can you please turn it off?"

I have to validate those bits too soon along with other parts.

If you don't set IEEE80211_C_TXFRAG then net80211 won't let userland configure fragthreshold, and won't create fragments itself. It's either both on or both off.

I think we're lacking the TX fragmentation offload option, where we allow userland to configure fragthreshold but then we don't do fragmentation in net80211 and let the driver/firmware sort it out.

In D49765#1135092, @bz wrote:

"Almost none of the drivers (save ath(4), which I fixed a long time ago) implement 802.11 fragments after the big VAP rework done years and years ago. "

Some drivers just say "let me do this in firmware... can you please turn it off?"

I have to validate those bits too soon along with other parts.

If you don't set IEEE80211_C_TXFRAG then net80211 won't let userland configure fragthreshold, and won't create fragments itself. It's either both on or both off.

I think we're lacking the TX fragmentation offload option, where we allow userland to configure fragthreshold but then we don't do fragmentation in net80211 and let the driver/firmware sort it out.

You set IEEE80211_C_TXFRAG for the ioctl and then you set ic->ic_flags_ext |= IEEE80211_FEXT_FRAG_OFFLOAD and the if (IEEE80211_CONF_FRAG_OFFLOAD(ic)) will prevent frags from being generated if I read it correctly a while ago. I just pushed the 2 line change fro LinuxKPI to main which has been lingering in a larger change in my tree.

In D49765#1135433, @bz wrote:
In D49765#1135092, @bz wrote:

"Almost none of the drivers (save ath(4), which I fixed a long time ago) implement 802.11 fragments after the big VAP rework done years and years ago. "

Some drivers just say "let me do this in firmware... can you please turn it off?"

I have to validate those bits too soon along with other parts.

If you don't set IEEE80211_C_TXFRAG then net80211 won't let userland configure fragthreshold, and won't create fragments itself. It's either both on or both off.

I think we're lacking the TX fragmentation offload option, where we allow userland to configure fragthreshold but then we don't do fragmentation in net80211 and let the driver/firmware sort it out.

You set IEEE80211_C_TXFRAG for the ioctl and then you set ic->ic_flags_ext |= IEEE80211_FEXT_FRAG_OFFLOAD and the if (IEEE80211_CONF_FRAG_OFFLOAD(ic)) will prevent frags from being generated if I read it correctly a while ago. I just pushed the 2 line change fro LinuxKPI to main which has been lingering in a larger change in my tree.

aha! rightio. yeah I saw / approved that. Very nice catch.

This revision was not accepted when it landed; it landed in state Needs Review.May 7 2025, 4:22 AM
This revision was automatically updated to reflect the committed changes.