rtwn: narrow the epoch area

[bz]

Summary

rtwn: narrow the epoch area

Rather than placing the epoch around the entire receive loop which
might call into rtwn_rx_frame() and USB and sleep, split the loop
into two and leave us with one unlock/lock cycle as well.

PR: 249925
Reported by:  thj, (rkoberman gmail.com)
Suggested by: adrian
Reviewed by:
Sponsored by:	The FreeBSD Foundation (initially)
Diff...:

[adrian]

I'm not a huge fan of this cause honestly we should be doing the epoch enter/exit around a batch.

What I was hoping to do was to create a list of frames from calls to rtwn_rx_frame and then push them up to the stack in a second pass under (a) no lock, avoiding the relock, and (b) being done in NET_EPOCH.

Wanna do that or should I?

[bz]

In D26554#591413, @adrian wrote:

I'm not a huge fan of this cause honestly we should be doing the epoch enter/exit around a batch.

What I was hoping to do was to create a list of frames from calls to rtwn_rx_frame and then push them up to the stack in a second pass under (a) no lock, avoiding the relock, and (b) being done in NET_EPOCH.

Wanna do that or should I?

I can; I have the code open and that's easy to do. I am still contemplating if acquiring the epoch in the driver code is the right thing.. but then all the epoch-ify-pushing-down has grinded to a halt.

[adrian]

Yeah, if we ever support pushing a list of receive frames into the net80211 stack, complete with rx status in the mbuf tags, then I think we can do this in net80211 quite nicely. :-)

[bz]

Rework as suggested by adrian.

[adrian]

sys/dev/rtwn/usb/rtwn_usb_rx.c

406 ↗

(On Diff #77561)

Lol, why isn't this node assignment thingy a net80211 method? That's a cute hack.