All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2] mac80211: do not aggregate frames if max_frags is set to one
Date: Thu, 30 Aug 2018 10:39:42 +0200	[thread overview]
Message-ID: <1535618382.5215.44.camel@sipsolutions.net> (raw)
In-Reply-To: <20180830083115.GA9867@localhost.localdomain> (sfid-20180830_103119_772533_DDBBD09F)

On Thu, 2018-08-30 at 10:31 +0200, Lorenzo Bianconi wrote:

> Reviewing the code I guess it is not necessary since pskb_expand_head routine
> does not modify head->len (or skb->len). 

True.

> Packet len (if we consider padding) is only modified in:
> 
> memset(skb_push(skb, pad), 0, pad);
> 
> and if we hit that point, we will account new skb->len in flow backlog. Do you
> agree?

Right, but that's the *pad*. I was thinking about the header conversion.

Let's say you decided to add the second frame to the A-MSDU, at which
point the first one isn't really an A-MSDU yet. So we get to:

        if (!ieee80211_amsdu_prepare_head(sdata, fast_tx, head))

which changes the header of "head" to be 14 bytes longer:

	skb_push(skb, sizeof(*amsdu_hdr));

But now let's say we get a failure here when reallocating the second
subframe:

        if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(rfc1042_header) +
                                                     2 + pad))
                goto out;

Now we have changed "head", which is on the FQ, but we haven't changed
the FQ accounting. So I *think* we still need this:

--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3239,7 +3239,7 @@ static bool ieee80211_amsdu_aggregate(struct ieee80211_sub_if_data *sdata,
 
 	if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(rfc1042_header) +
 						     2 + pad))
-		goto out;
+		goto out_recalc;
 
 	ret = true;
 	data = skb_push(skb, ETH_ALEN + 2);
@@ -3256,11 +3256,13 @@ static bool ieee80211_amsdu_aggregate(struct ieee80211_sub_if_data *sdata,
 	head->data_len += skb->len;
 	*frag_tail = skb;
 
-	flow->backlog += head->len - orig_len;
-	tin->backlog_bytes += head->len - orig_len;
-
-	fq_recalc_backlog(fq, tin, flow);
+out_recalc:
+	if (head->len != orig_len) {
+		flow->backlog += head->len - orig_len;
+		tin->backlog_bytes += head->len - orig_len;
 
+		fq_recalc_backlog(fq, tin, flow);
+	}
 out:
 	spin_unlock_bh(&fq->lock);
 


> Looking at the code maybe I spotted another issue, I guess there is an
> off-by-one issue in 'n' estimation since it does not take into account
> the first frame. We hit the line:
> 
> while (*frag_tail) {
> }
> 
> starting from the second subframe, but if the head does not have packet in the
> fraglist we will end up having n = 1, while it is actually the second frame.

Hmm, not sure I follow? "head" is the A-MSDU, containing the A-MSDU
header and the first subframe in skb->data (and/or frags), with the
subframes 2..N in the fraglist.

So I think this is right?

johannes

  reply	other threads:[~2018-08-30 12:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1535567864.git.lorenzo.bianconi@redhat.com>
2018-08-29 19:03 ` [PATCH v2] mac80211: do not aggregate frames if max_frags is set to one Lorenzo Bianconi
2018-08-29 19:05   ` Johannes Berg
2018-08-29 19:12     ` Lorenzo Bianconi
     [not found]       ` <1535570007.5215.34.camel@sipsolutions.net>
2018-08-29 19:30         ` Lorenzo Bianconi
2018-08-30  8:03           ` Johannes Berg
2018-08-30  8:31             ` Lorenzo Bianconi
2018-08-30  8:39               ` Johannes Berg [this message]
2018-08-30  8:50                 ` Lorenzo Bianconi
2018-08-30  8:53                   ` Johannes Berg
2018-08-30  9:00                     ` Lorenzo Bianconi
2018-08-30  9:03                       ` Johannes Berg
2018-08-30  9:06                         ` Johannes Berg
2018-08-30  9:07                         ` Lorenzo Bianconi
2018-08-30  9:07                           ` 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=1535618382.5215.44.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    /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.