Searched hist:250326 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sys/dev/ath/ | ||
| H A D | if_athioctl.h | diff 250326 Tue May 07 06:03:03 MDT 2013 adrian Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379 |
| H A D | if_ath.c | diff 250326 Tue May 07 06:03:03 MDT 2013 adrian Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379 |
Completed in 267 milliseconds