Page MenuHomeFreeBSD

net80211: add a TX mbufq to ieee80211_node to be managed by drivers
AbandonedPublic

Authored by bz on Jun 5 2021, 5:18 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 10 2024, 3:20 PM
Unknown Object (File)
Dec 20 2023, 2:02 AM
Unknown Object (File)
Dec 12 2023, 5:22 PM
Unknown Object (File)
Nov 28 2023, 5:38 AM
Unknown Object (File)
Nov 23 2023, 12:20 AM
Unknown Object (File)
Nov 22 2023, 11:53 PM
Unknown Object (File)
Nov 14 2023, 2:01 AM
Unknown Object (File)
Nov 13 2023, 6:05 PM

Details

Reviewers
adrian
Group Reviewers
wireless
Summary

For recent drivers we run into issues on TX in that we can
malloc/sleep. For the moment rather than replicating some logic
into drivers or compat framework start migrating a per-node mbufq
into net80211 and let the driver manage it. This allows the driver
to defer the TX for now avoiding locking issues.
Eventually the net80211/driver TX interface should improve and
most of the needed should be done in net80211.
I am just not there yet as to know what exactly we will end up with
so taking it one step at a time.

Also add a drv_data pointer where the driver can store state,
e.g., to backtrack its own internal view on the node.

Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
X-MFC: wait longer, I just want the email

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 39733
Build 36622: arc lint + arc unit

Event Timeline

bz requested review of this revision.Jun 5 2021, 5:18 PM

@adrian from my understanding this would also help "athp" in one of its recent incarnations to get some FreeBSD specific code out of the driver.

I am not entirely happy with this but keeping it stuck in a development branch will not help the discussion either so putting it out here.

Yeah, I was thinking the same thing. It gets a bit unfun when we start looking at how we drain this versus direct dispatch, but let's tackle that later.

(ath and athp have the same thing.. ugh)

This revision is now accepted and ready to land.Jun 5 2021, 5:23 PM

I assume there's more coming that uses this interface? Without seeing how this is gonna be used I think you should hold onto this.

I'll add the ni_drv_data pointer but apart from this I am abandoning this.
Doesn't seem right to have it there anymore.
A lot more to figure out properly first.