Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: debugging TXQs being empty
To:     Johannes Berg <johannes@sipsolutions.net>,
        Kan Yan <kyan@google.com>
Cc:     =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= <toke@redhat.com>,
        linux-wireless <linux-wireless@vger.kernel.org>
References: <bbc516f28782175b27ac5e19dcdeac13cd6ee76a.camel@sipsolutions.net>
 <fd23a26dea59128ede8c1c4d02fb2f3514ffb5e9.camel@sipsolutions.net>
 <CA+iem5tjTpO_2MKL_pEu7enTa-8=g5vY3=2WJKjg9f=JA2eCEw@mail.gmail.com>
 <9b89b3b294295063aec045b9e863a44ad20b8782.camel@sipsolutions.net>
 <bf0cced86a1466285f74eb845e73fbaea1dff1c0.camel@sipsolutions.net>
From:   Koen Vandeputte <koen.vandeputte@ncentric.com>
Message-ID: <a4895e13-5d18-f151-e558-a3be1ed065ce@ncentric.com>
Date:   Fri, 6 Dec 2019 11:22:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <bf0cced86a1466285f74eb845e73fbaea1dff1c0.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk


On 06.12.19 10:12, Johannes Berg wrote:
> On Fri, 2019-12-06 at 09:41 +0100, Johannes Berg wrote:
>> Maybe somehow TSO is interacting badly with the TXQs and the tracking
>> here, since TSO makes the traffic *very* bursty? A 64k packet in the
>> driver will typically expand to 9 or 10 A-MSDUs I think?
> No, that all seems well. Without TSO (with the trivial mac80211 patch to
> let me turn it off with ethtool) I get about 890Mbps, so about 5% less.
> That's not actually *that* bad, I guess due to software A-MSDU in
> mac80211, but it's not really the right direction :)
If you try this test again while setting coverage class higher (20000m 
or so), you *will* notice the difference a *lot* more (>50%) :-)
Even when the actual devices are only a few meters apart.
>
> Changing wmem_max/tcp_mem to outrageous values also didn't really make
> any difference.
>
> I guess it's time to see if I can poke into the TCP stack to figure out
> what's going on...
>
> johannes
>