Hi,
is there any reason the packet is dropped and "NETDEV_TX_OK" is returned,
in this case?
Seems pretty stupid to me, because now we are randomly dropping
packets before kernel queuing (qdisc etc) can handle them,
or am I missing something?
Best regards,
Arnd
On Tue, Nov 10, 2009 at 12:12 PM, Arnd Hannemann
<[email protected]> wrote:
> Hi,
>
> is there any reason the packet is dropped and "NETDEV_TX_OK" is returned,
> in this case?
> Seems pretty stupid to me, because now we are randomly dropping
> packets before kernel queuing (qdisc etc) can handle them,
> or am I missing something?
Yes, there is a good reason (there are no buffers for the hardware to
play with). Actually mac80211 tx is never supposed to return anything
but TX_OK.
Try this patch (it needs work which is why it's not upstream yet):
http://patchwork.kernel.org/patch/56785/
--
Bob Copeland %% http://www.bobcopeland.com
On Saturday 09 January 2010 04:41:32 Bob Copeland wrote:
> Ok, well the patch only will affect AP mode -- it addresses a bug where
> multicast AP frames are queued but not always processed. I wonder if your
> workload is just filling up the queues and then the queues are awakened
> prematurely. There's a check in ath5k_tx_processq to only re-enable the
> queue when there are 40 tx buffers left, but there are a few other paths
> that re-enable the queues -- also accounting on txbuf_len could
> theoretically get broken.
>
> Maybe a printk in ath5k_tx_queue of sc->txbuf_len caN show how many buffers
> are typically available when entering?
I put a printk debug statement in ath5k_tx_queue() to see how sc->txbuf_len
changes. The maximum number of buffers is 200 as defined by ATH_TXBUF. During
the file transfer, sometimes, sc>txbuf_len decreases up to 1, then it changes
to 41 and starts again to decrease up to 1, again 41 and so on for a few
seconds. When the buffer number is 0 I can see the "no further txbuf available,
dropping packet" message.
Fabio
Hi Bob,
I have tried your patch as I get many errors as in subject when I transfer
huge files (I'm using as a test a 1GB file). With the patch I have the same
errors.
I'm using wireless-testing.git (v2.6.33-rc2-47131-gc72a18c) in managed mode
(no AP).
Fabio
On Wednesday 11 November 2009 05:13:03 Bob Copeland wrote:
> Yes, there is a good reason (there are no buffers for the hardware to
> play with). Actually mac80211 tx is never supposed to return anything
> but TX_OK.
>
> Try this patch (it needs work which is why it's not upstream yet):
>
> http://patchwork.kernel.org/patch/56785/
>
On Mon, Jan 11, 2010 at 7:19 PM, Fabio Rossi <[email protected]> wrote:
> I put a printk debug statement in ath5k_tx_queue() to see how sc->txbuf_len
> changes. The maximum number of buffers is 200 as defined by ATH_TXBUF. During
> the file transfer, sometimes, sc>txbuf_len decreases up to 1, then it changes
> to 41 and starts again to decrease up to 1, again 41 and so on for a few
> seconds. When the buffer number is 0 I can see the "no further txbuf available,
> dropping packet" message.
Ok, well then at least we know that it is working :) Do you get any ill effects
besides the log spam? If so then there could be an issue with starvation of the
processing tasklet. Or maybe we should look at changing the limits
for better flow.
We could also stop the queues a packet earlier, I guess.
--
Bob Copeland %% http://www.bobcopeland.com
On Tuesday 12 January 2010 17:35:04 Bob Copeland wrote:
> Ok, well then at least we know that it is working :) Do you get any ill
> effects besides the log spam? If so then there could be an issue with
> starvation of the processing tasklet. Or maybe we should look at changing
> the limits for better flow.
I don't have problems with the connection but sometimes it's seems less
responsive, for instance it seems the latency in loading the web pages is
longer. Of course this is a personal impression.
I'm available to test any patches if you think the behavior may be improved,
also simply to investigate more on the issue.
Fabio
On Fri, Jan 08, 2010 at 11:34:16PM +0100, Fabio Rossi wrote:
> Hi Bob,
> I have tried your patch as I get many errors as in subject when I transfer
> huge files (I'm using as a test a 1GB file). With the patch I have the same
> errors.
>
> I'm using wireless-testing.git (v2.6.33-rc2-47131-gc72a18c) in managed mode
> (no AP).
Ok, well the patch only will affect AP mode -- it addresses a bug where
multicast AP frames are queued but not always processed. I wonder if your
workload is just filling up the queues and then the queues are awakened
prematurely. There's a check in ath5k_tx_processq to only re-enable the
queue when there are 40 tx buffers left, but there are a few other paths
that re-enable the queues -- also accounting on txbuf_len could theoretically
get broken.
Maybe a printk in ath5k_tx_queue of sc->txbuf_len caN show how many buffers
are typically available when entering?
--
Bob Copeland %% http://www.bobcopeland.com