Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread Alan Ott
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread Werner Almesberger
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread David Miller
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread Alan Ott
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread David Miller
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread Alan Ott
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread David Miller
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread Alan Ott
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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

2013-04-02 Thread Werner Almesberger
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