mirror of
https://git.FreeBSD.org/src.git
synced 2025-01-24 16:10:11 +00:00
8e7393944d
it run out of multiple concurrent contexts. Right now the ath(4) TX processing is a bit hairy. Specifically: * It was running out of ath_start(), which could occur from multiple concurrent sending processes (as if_start() can be started from multiple sending threads nowdays.. sigh) * during RX if fast frames are enabled (so not really at the moment, not until I fix this particular feature again..) * during ath_reset() - so anything which calls that * during ath_tx_proc*() in the ath taskqueue - ie, TX is attempted again after TX completion, as there's now hopefully some ath_bufs available. * Then, the ic_raw_xmit() method can queue raw frames for transmission at any time, from any net80211 TX context. Ew. This has caused packet ordering issues in the past - specifically, there's absolutely no guarantee that preemption won't occuring _during_ ath_start() by the TX completion processing, which will call ath_start() again. It's a mess - 802.11 really, really wants things to be in sequence or things go all kinds of loopy. So: * create a new task struct for TX'ing; * make the if_start method simply queue the task on the ath taskqueue; * make ath_start() just be called by the new TX task; * make ath_tx_kick() just schedule the ath TX task, rather than directly calling ath_start(). Now yes, this means that I've taken a step backwards in terms of concurrency - TX -and- RX now occur in the same single-task taskqueue. But there's nothing stopping me from separating out the TX / TX completion code into a separate taskqueue which runs in parallel with the RX path, if that ends up being appropriate for some platforms. This fixes the CCMP/seqno concurrency issues that creep up when you transmit large amounts of uni-directional UDP traffic (>200MBit) on a FreeBSD STA -> AP, as now there's only one TX context no matter what's going on (TX completion->retry/software queue, userland->net80211->ath_start(), TX completion -> ath_start()); but it won't fix any concurrency issues between raw transmitted frames and non-raw transmitted frames (eg EAPOL frames on TID 16 and any other TID 16 multicast traffic that gets put on the CABQ.) That is going to require a bunch more re-architecture before it's feasible to fix. In any case, this is a big step towards making the majority of the TX path locking irrelevant, as now almost all TX activity occurs in the taskqueue. Phew. |
||
---|---|---|
.. | ||
amd64 | ||
arm | ||
boot | ||
bsm | ||
cam | ||
cddl | ||
compat | ||
conf | ||
contrib | ||
crypto | ||
ddb | ||
dev | ||
fs | ||
gdb | ||
geom | ||
gnu/fs | ||
i386 | ||
ia64 | ||
isa | ||
kern | ||
kgssapi | ||
libkern | ||
mips | ||
modules | ||
net | ||
net80211 | ||
netatalk | ||
netgraph | ||
netinet | ||
netinet6 | ||
netipsec | ||
netipx | ||
netnatm | ||
netncp | ||
netpfil | ||
netsmb | ||
nfs | ||
nfsclient | ||
nfsserver | ||
nlm | ||
ofed | ||
opencrypto | ||
pc98 | ||
pci | ||
powerpc | ||
rpc | ||
security | ||
sparc64 | ||
sys | ||
teken | ||
tools | ||
ufs | ||
vm | ||
x86 | ||
xdr | ||
xen | ||
Makefile |