public inbox for b43-dev@lists.infradead.org
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: "Michael Büsch" <m@bues.ch>
Cc: linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org,
	francesco.gringoli@ing.unibs.it, "Michael Büsch" <mb@bu3sch.de>
Subject: [RFC][PATCH] b43: do not try sending packets when ring can be full
Date: Sun, 12 Jun 2011 20:15:53 +0200	[thread overview]
Message-ID: <BANLkTikVLH8xApD4e5uNW-3Eg6kaMXipBg@mail.gmail.com> (raw)
In-Reply-To: <20110612182916.6afc781a@maggie>

2011/6/12 Michael B?sch <m@bues.ch>:
> On Sun, 12 Jun 2011 17:11:53 +0200
> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>
>> ---
>> This prevents us from hitting "Packet after queue stopped", but still
>> is not an optimal solution. We stop sending packets from queue to
>> hardware if just a one ring is full. It may happen there are packets on
>> the queue that want to be send to different ring (qos).
>> ---
>> ?drivers/net/wireless/b43/b43.h ?| ? ?2 ++
>> ?drivers/net/wireless/b43/dma.c ?| ? ?5 +++++
>> ?drivers/net/wireless/b43/main.c | ? ?5 +++++
>> ?3 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
>> index 1cb2dde..8d4bb28 100644
>> --- a/drivers/net/wireless/b43/b43.h
>> +++ b/drivers/net/wireless/b43/b43.h
>> @@ -582,6 +582,8 @@ struct b43_dma {
>> ? ? ? struct b43_dmaring *rx_ring;
>>
>> ? ? ? u32 translation; /* Routing bits */
>> +
>> + ? ? u8 stopped_rings; /* Amount of stopped rings */
>> ?};
>>
>> ?struct b43_pio_txqueue;
>> diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
>> index d02cf83..a501992 100644
>> --- a/drivers/net/wireless/b43/dma.c
>> +++ b/drivers/net/wireless/b43/dma.c
>> @@ -1056,6 +1056,7 @@ int b43_dma_init(struct b43_wldev *dev)
>> ? ? ? if (err)
>> ? ? ? ? ? ? ? return err;
>> ? ? ? dma->translation = ssb_dma_translation(dev->sdev);
>> + ? ? dma->stopped_rings = 0;
>>
>> ? ? ? err = -ENOMEM;
>> ? ? ? /* setup TX DMA channels. */
>> @@ -1374,6 +1375,8 @@ int b43_dma_tx(struct b43_wldev *dev, struct sk_buff *skb)
>> ? ? ? ? ? ? ? /* This TX ring is full. */
>> ? ? ? ? ? ? ? ieee80211_stop_queue(dev->wl->hw, skb_get_queue_mapping(skb));
>> ? ? ? ? ? ? ? ring->stopped = 1;
>> + ? ? ? ? ? ? dev->dma.stopped_rings++;
>> +
>> ? ? ? ? ? ? ? if (b43_debug(dev, B43_DBG_DMAVERBOSE)) {
>> ? ? ? ? ? ? ? ? ? ? ? b43dbg(dev->wl, "Stopped TX ring %d\n", ring->index);
>> ? ? ? ? ? ? ? }
>> @@ -1493,9 +1496,11 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev,
>> ? ? ? ? ? ? ? B43_WARN_ON(free_slots(ring) < TX_SLOTS_PER_FRAME);
>> ? ? ? ? ? ? ? ieee80211_wake_queue(dev->wl->hw, ring->queue_prio);
>> ? ? ? ? ? ? ? ring->stopped = 0;
>> + ? ? ? ? ? ? dev->dma.stopped_rings--;
>> ? ? ? ? ? ? ? if (b43_debug(dev, B43_DBG_DMAVERBOSE)) {
>> ? ? ? ? ? ? ? ? ? ? ? b43dbg(dev->wl, "Woke up TX ring %d\n", ring->index);
>> ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ieee80211_queue_work(dev->wl->hw, &dev->wl->tx_work);
>> ? ? ? }
>> ?}
>>
>> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
>> index 1d8d983..2260b36 100644
>> --- a/drivers/net/wireless/b43/main.c
>> +++ b/drivers/net/wireless/b43/main.c
>> @@ -3219,6 +3219,11 @@ static void b43_tx_work(struct work_struct *work)
>> ? ? ? }
>>
>> ? ? ? while (skb_queue_len(&wl->tx_queue)) {
>> + ? ? ? ? ? ? if (!b43_using_pio_transfers(dev) && dev->dma.stopped_rings) {
>> + ? ? ? ? ? ? ? ? ? ? mutex_unlock(&wl->mutex);
>> + ? ? ? ? ? ? ? ? ? ? return;
>> + ? ? ? ? ? ? }
>> +
>> ? ? ? ? ? ? ? skb = skb_dequeue(&wl->tx_queue);
>>
>> ? ? ? ? ? ? ? if (b43_using_pio_transfers(dev))
>
> This can probably serve as a quick workaround, as long as a real fix is being developed.

Yeah, that's what my summary/comment say :)


> I'm not sure if multiple queues are needed for this to work. I think it could work
> with a single queue as well. We just must not _unqueue_ it, if we are unable to transmit
> it due to stopped ring. I don't know if there are skb_queue mechanisms that help
> us achieve this.

Well, as I said, we may be unable to transmit the first element of the
queue, but 2nd/3rd/... may be for different ring (qos) (we can
transmit).

Looping through the whole queue every time, just to find packets we
may transmit, sounds surely as a bad idea.

The only idea I've right now, are separated TX skb queues, one for each qos.

-- 
Rafa?

  reply	other threads:[~2011-06-12 18:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-12 15:11 [RFC][PATCH] b43: do not try sending packets when ring can be full Rafał Miłecki
2011-06-12 14:36 ` Rafał Miłecki
2011-06-12 16:29 ` Michael Büsch
2011-06-12 18:15   ` Rafał Miłecki [this message]
2011-06-12 18:48     ` Michael Büsch
2011-06-12 19:07       ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTikVLH8xApD4e5uNW-3Eg6kaMXipBg@mail.gmail.com \
    --to=zajec5@gmail.com \
    --cc=b43-dev@lists.infradead.org \
    --cc=francesco.gringoli@ing.unibs.it \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m@bues.ch \
    --cc=mb@bu3sch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox