Date: Wed, 19 Feb 2020 17:01:58 -0800 From: Adrian Chadd <adrian@freebsd.org> To: FreeBSD Net <freebsd-net@freebsd.org> Subject: epoch and ath(4) - what should we be doing? Message-ID: <CAJ-VmokqMzB-hGMOEwJ-1R3wsOzrL16jOqC58c34gM1CM00gPQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
hi! I'd like to update ath(4) to properly work with epoch, as that whole "oh make taskqueues epoch aware" is just not enough for ath(4). Background: * receive is done using deferred taskqueues, but * receive queues are drained/handled too outside of taskqueues - notably during interface resets, in order to not drop frames. So I'd like to convert it over to a normal taskqueue and just manually do EPOCH_ENTER / EPOCH_EXIT. It also means I can pepper assertions around ath(4) and net80211(4) to ensure that we're properly entering things with epoch held or not held. Questions: * are these things recursive? * what are the rules around sleeping? I've seen some ... discussions that were quite animated around this. * what should I be doing as an epoch tracker if I could call the receive routine from multiple paths. I see a few drivers have a single place where they're doing EPOCH_ENTER/EPOCH_EXIT using an epoch tracker allocated in the interrupt handler stack, but what if I also want to call that receive path from another function path too? Can I just stuff an epoch_tracker on the stack and it'll DTRT ? * .. is there some updated doc or brain dump somewhere I can read? I'd like to go add this to a couple out of tree wifi drivers under development so this would make that whole thing much easier. Thanks! -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokqMzB-hGMOEwJ-1R3wsOzrL16jOqC58c34gM1CM00gPQ>