So I cheaped out for now and just wrapped the ath TX path in a new TX only lock.
I'm open to other suggestions about how to make the "queue everything
through a taskqueue" work, but unfortunately it seems that I'm
defeated by the inner workings of the network stack locking and how
that plays with
The problem with this is that fragments need to be handed as an entire
list to the driver.
ath(4) looks ahead to the next fragment, calculates the rate, and then
adds that to the NAV of the previous frame.
So yeah what I'm thinking about for now is something like the following:
* say that wifi d
On Mon, Oct 29, 2012 at 3:47 AM, Andre Oppermann wrote:
> On 29.10.2012 04:53, Adrian Chadd wrote:
>>
>> On 28 October 2012 20:43, PseudoCylon wrote:
>>
>>> Cannot we just add custom hand off function to ieee80211_start()?
>>
>>
>> Yes. That's the general idea. But what I don't want to do is have
On 29.10.2012 04:53, Adrian Chadd wrote:
On 28 October 2012 20:43, PseudoCylon wrote:
Cannot we just add custom hand off function to ieee80211_start()?
Yes. That's the general idea. But what I don't want to do is have it
just wake up the driver TX taskqueue - well, unless we have to.
That m
On 28 October 2012 20:43, PseudoCylon wrote:
> Cannot we just add custom hand off function to ieee80211_start()?
Yes. That's the general idea. But what I don't want to do is have it
just wake up the driver TX taskqueue - well, unless we have to.
That means we'll have two context switches for ea
> --
>
> Message: 1
> Date: Sat, 27 Oct 2012 16:18:11 -0700
> From: Adrian Chadd
> To: freebsd-wirel...@freebsd.org
> Cc: FreeBSD Net , freebsd-a...@freebsd.org
> Subject: request for help: 'fixing&
Hi all,
I'd like to try and sort out the last remaining niggles in the 802.11
code - this email is focusing on the TX path.
The TX path has a few problems:
* there's a normal versus raw TX path (for raw frames, management
frames, etc) - the raw path doesn't necessarily queue frames into the
raw
