All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>,
	"Luis R. Rodriguez" <mcgrof@bombadil.infradead.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC] mac80211: move TX status processing to process context
Date: Wed, 18 Nov 2009 13:06:54 -0800	[thread overview]
Message-ID: <20091118210654.GI6581@tux> (raw)
In-Reply-To: <1258576479.30511.65.camel@johannes.local>

On Wed, Nov 18, 2009 at 12:34:39PM -0800, Johannes Berg wrote:
> On Wed, 2009-11-18 at 12:23 -0800, Luis R. Rodriguez wrote:
> 
> > > > > +	/* if we got over the limit with this frame, try to make room */
> > > > > +	if (num > IEEE80211_TX_STATUS_QUEUE_LIMIT &&
> > > > > +	    (skb = skb_dequeue(&local->tx_status_unreliable))) {
> > > > >  		dev_kfree_skb_irq(skb);
> > > > 
> > > > Note before there was a while loop and now just a if branch. Why can we
> > > > get away with freeing now just one buffer? It would be nice to see
> > > > this explained in the commit log entry as it is not obvious to me.
> > > 
> > > Ah yes, I meant to explain that. We only use the status queues for TX
> > > status now and not for RX too as before, so before it could actually
> > > happen that we could free more than one off the unreliable queue, while
> > > now it really can only be one.
> > 
> > Ah, thanks, so, that skb_queue can go and we can just have one
> > unreliable sk_buff ?
> 
> No, you misunderstood. Because I'm separating the queue for the tasklet
> (tasklet_queue) and for TX status (tx_status/tx_status_unreliable) we
> can only possibly free one since we only added one -- the count cannot
> increase over that. The loop would only loop once at most.

OK, but can't you still have a driver spam mac80211 with a lot of
ieee80211_tx_status_irqsafe() calls in soft irq context with the final
skb requiring the tx complete, in that case the queue *will* get stuffed
and you could potentially free more if so desired.

Also, if our goal is to just avoid adding the skb if it does not require
a tx complete and our queue size is too large

	if (!(info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS) &&
	    num + 1 > IEEE80211_TX_STATUS_QUEUE_LIMIT)
		dev_kfree_skb_irq(skb);
	else
		skb_queue_tail(&local->skb_queue)

> However ... right now we never use _any_ unreliable at all, but I
> suspect we will want to change that again at some point.

Just curious -- what would be a use case for that?

  Luis

  reply	other threads:[~2009-11-18 21:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-18 19:16 [RFC] mac80211: move TX status processing to process context Johannes Berg
2009-11-18 19:53 ` Luis R. Rodriguez
2009-11-18 20:01   ` Johannes Berg
2009-11-18 20:23     ` Luis R. Rodriguez
2009-11-18 20:34       ` Johannes Berg
2009-11-18 21:06         ` Luis R. Rodriguez [this message]
2009-11-18 21:11           ` Johannes Berg
2009-11-18 21:15             ` Luis R. Rodriguez
2009-11-18 21:12           ` Luis R. Rodriguez
2009-11-18 21:13             ` Johannes Berg
2009-11-19 13:34 ` Johannes Berg

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=20091118210654.GI6581@tux \
    --to=lrodriguez@atheros.com \
    --cc=Luis.Rodriguez@Atheros.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@bombadil.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.