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

[adrian]

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.

[bz]

"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.

[adrian]

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.

[bz]

In D49765#1135217, @adrian 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.

[adrian]

In D49765#1135433, @bz wrote:

In D49765#1135217, @adrian 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.