On 04/02/2013 10:30 PM, David Miller wrote:
> From: Alan Ott
> Date: Tue, 02 Apr 2013 22:25:28 -0400
>
>> The workqueue in mac802154 is only needed because the current mac802154
>> xmit() function is designed to be blocking and synchronous.
>>
>> Prior to my patch (#3/6), that very same workqueue
Alan Ott wrote:
> 1. Most supported devices have only single packet output buffer, so
> blocking in the driver is the most straight-forward way to handle it.
> The alternative is to make each driver have a workqueue for xmit() (to
> lift the blocking out from atomic context). This makes each driver
From: Alan Ott
Date: Tue, 02 Apr 2013 22:25:28 -0400
> The workqueue in mac802154 is only needed because the current mac802154
> xmit() function is designed to be blocking and synchronous.
>
> Prior to my patch (#3/6), that very same workqueue would actually queue
> up packets (without bound). T
On 04/02/2013 10:03 PM, David Miller wrote:
> From: Alan Ott
> Date: Tue, 02 Apr 2013 21:59:37 -0400
>
>> On 04/02/2013 09:56 PM, David Miller wrote:
>>> From: Alan Ott
>>> Date: Tue, 02 Apr 2013 21:24:59 -0400
>>>
I like it for a couple of reasons.
1. Most supported devices have only s
From: Alan Ott
Date: Tue, 02 Apr 2013 21:59:37 -0400
> On 04/02/2013 09:56 PM, David Miller wrote:
>> From: Alan Ott
>> Date: Tue, 02 Apr 2013 21:24:59 -0400
>>
>>> I like it for a couple of reasons.
>>> 1. Most supported devices have only single packet output buffer, so
>>> blocking in the driv
On 04/02/2013 09:56 PM, David Miller wrote:
> From: Alan Ott
> Date: Tue, 02 Apr 2013 21:24:59 -0400
>
>> I like it for a couple of reasons.
>> 1. Most supported devices have only single packet output buffer, so
>> blocking in the driver is the most straight-forward way to handle it.
>> The altern
From: Alan Ott
Date: Tue, 02 Apr 2013 21:24:59 -0400
> I like it for a couple of reasons.
> 1. Most supported devices have only single packet output buffer, so
> blocking in the driver is the most straight-forward way to handle it.
> The alternative is to make each driver have a workqueue for xmi
On 04/02/2013 07:13 PM, Werner Almesberger wrote:
> Alan Ott wrote:
>> it's now my opinion that we should _not_ try to retransmit at
>> all in mac802154/tx.c.
> I think the currently blocking workqueue design is ugly and
> quite contrary to how most the rest of the stack works. So
> anything that k
Alan Ott wrote:
> it's now my opinion that we should _not_ try to retransmit at
> all in mac802154/tx.c.
I think the currently blocking workqueue design is ugly and
quite contrary to how most the rest of the stack works. So
anything that kills it has my blessing :-)
I do wonder though why it was
On 04/02/2013 05:28 PM, Alan Ott wrote:
> According to 7.5.6.5 of IEEE 802.15.4-2003, if the retransmission fails
> more than aMaxFrameRetries (3) times, it is assumed that it has failed.
> Since some transceivers (and I would assume most if not all) do this in
> hardware, it's now my opinion that
On 04/02/2013 04:28 PM, Alan Ott wrote:
> On 04/02/2013 03:11 PM, Alexander Smirnov wrote:
>> 2013/4/2 Alan Ott mailto:a...@signal11.us>>
>>
>> When ops->xmit() fails, immediately retry. Previously the packet was
>> sent
>> to the back of the workqueue.
>>
>> Signed-off-by: Alan Ott
On 04/02/2013 03:11 PM, Alexander Smirnov wrote:
> 2013/4/2 Alan Ott mailto:a...@signal11.us>>
>
> When ops->xmit() fails, immediately retry. Previously the packet was
> sent
> to the back of the workqueue.
>
> Signed-off-by: Alan Ott mailto:a...@signal11.us>>
> ---
> net
When ops->xmit() fails, immediately retry. Previously the packet was sent
to the back of the workqueue.
Signed-off-by: Alan Ott
---
net/mac802154/tx.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 4e09d07..fbf9
13 matches
Mail list logo
