On Tue, Feb 19, 2013 at 7:01 PM, Adrian Chadd wrote:
> On 19 February 2013 09:44, Monthadar Al Jaberi wrote:
>
>> I have tested between two meshSTAand run iperf UDP until I get close
>> to getting lost packets.
>>
>> Current FreeBSD (r246983): 17 Mbits/
>> Current FreeBSD (r246983) + with your pa
On 19 February 2013 09:44, Monthadar Al Jaberi wrote:
> I have tested between two meshSTAand run iperf UDP until I get close
> to getting lost packets.
>
> Current FreeBSD (r246983): 17 Mbits/
> Current FreeBSD (r246983) + with your patch: 15 Mbit/s
>
> Good news no panic! But looks like a bit sl
On Tue, Feb 19, 2013 at 5:49 PM, Adrian Chadd wrote:
> On 19 February 2013 07:50, Monthadar Al Jaberi wrote:
>> On Tue, Feb 19, 2013 at 4:10 PM, Adrian Chadd wrote:
>>> Here's my current patch. I've tested it lightly in AP mode.
>>
>> Its identical to 20130216-net80211-tx-lock-2.diff?
>>
>
> Goo
On 19 February 2013 07:50, Monthadar Al Jaberi wrote:
> On Tue, Feb 19, 2013 at 4:10 PM, Adrian Chadd wrote:
>> Here's my current patch. I've tested it lightly in AP mode.
>
> Its identical to 20130216-net80211-tx-lock-2.diff?
>
Good. That means I haven't accidentally changed anything since the
On Tue, Feb 19, 2013 at 4:10 PM, Adrian Chadd wrote:
> Here's my current patch. I've tested it lightly in AP mode.
Its identical to 20130216-net80211-tx-lock-2.diff?
>
>
>
> Adrian
--
Monthadar Al Jaberi
___
freebsd-wireless@freebsd.org mailing lis
Here's my current patch. I've tested it lightly in AP mode.
Adrian
20130218-net80211-tx-lock-3.diff
Description: Binary data
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send
oh.. right. We talked about this on irc a bit. Yes,
mesh_transmit_to_gate() looks like a copy of what I put in
ieee80211_start_pkt().
We'll refactor this common code out later. :-)
Same as what we should do with the rest of the duplicate code in the
input path for various net80211 modules..
adr
On 18 February 2013 02:05, Monthadar Al Jaberi wrote:
> On Sun, Feb 17, 2013 at 1:46 AM, Adrian Chadd wrote:
>> Here's version two of the patch: it includes the rest of the TX paths
>> locked as well as some extra assertions about the state of the TX lock
>> requirements.
>
> Why not make ieee802
On Sun, Feb 17, 2013 at 1:46 AM, Adrian Chadd wrote:
> Here's version two of the patch: it includes the rest of the TX paths
> locked as well as some extra assertions about the state of the TX lock
> requirements.
Why not make ieee80211_start_pkt public? So that we can call it from
mesh_transmit_
Here's version two of the patch: it includes the rest of the TX paths
locked as well as some extra assertions about the state of the TX lock
requirements.
I've only lightly tested this in STA mode. I haven't yet really tested
this in hostap mode. I gather it's going to panic all the things.
Thus,
Hi,
Here's the patch:
* break out the per-packet send code into ieee80211_start_pkt()
* introduce a per-vap TX lock
* wrap the normal TX path ieee80211_encap(), parent->if_transmit and
ic->ic_raw_xmit with the TX lock
TODO:
* the rest of the encap calls need to be wrapped in the TX lock - wds,
Yeah - gluing TX into a single send queue is going to work, but
there's definite queuing / QoS issues. You really want the management
frames to be able to go out even if there's a _large_ amount of data
frames going out. That's a side-issue though.
I have a test patch that just wraps the output, m
On Fri, Feb 15, 2013 at 4:03 PM, Adrian Chadd wrote:
> The (many) problems include the two TX paths - one is via _start /
> _transmit, and one is the raw xmit path.
>
> So in the short term it'll be easier (!) to just wrap all TX entry
> points with a VAP TX lock.
> Once that's done and we've debu
The (many) problems include the two TX paths - one is via _start /
_transmit, and one is the raw xmit path.
So in the short term it'll be easier (!) to just wrap all TX entry
points with a VAP TX lock.
Once that's done and we've debugged it, we can look at breaking it
into a queue with a taskqueue
> --
>
> Message: 2
> Date: Wed, 13 Feb 2013 21:14:53 -0800
> From: Adrian Chadd
> To: freebsd-wireless@freebsd.org
> Subject: [RFC] serialising net80211 TX
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> I'd like to work on the net80
On Fri, Feb 15, 2013 at 2:49 AM, Adrian Chadd wrote:
> On 14 February 2013 11:50, Monthadar Al Jaberi wrote:
>
>> Seems like the best architectural wise, first-in first out. I am just
>> thinking of one can extend this too have like more than one queue,
>> more like the QoS concept, and each pack
On 14 February 2013 11:50, Monthadar Al Jaberi wrote:
> Seems like the best architectural wise, first-in first out. I am just
> thinking of one can extend this too have like more than one queue,
> more like the QoS concept, and each packet have a time-stamp assigned
> to it.Would that help?
Well
On Thu, Feb 14, 2013 at 6:14 AM, Adrian Chadd wrote:
> Hi,
>
> I'd like to work on the net80211 TX serialisation now. I'll worry
> about driver serialisation and if_transmit methods later.
>
> The 30 second version - it happens in parallel, which means preemption
> and multi-core devices can and w
18 matches
Mail list logo
