netdev - Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0BA3FCBA62E2DC44AF3030971E174FB32E82654B@hasmsx107.ger.corp.intel.com>
Date:	Thu, 20 Aug 2015 13:53:09 +0000
From:	"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"ido@...ery.com" <ido@...ery.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Sharon, Sara" <sara.sharon@...el.com>
Subject: Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last
 TSO segment



On 08/20/2015 04:11 PM, Eric Dumazet wrote:
> On Thu, 2015-08-20 at 06:21 +0000, Grumbach, Emmanuel wrote:
>>
>> On 08/19/2015 11:39 PM, Eric Dumazet wrote:
>>> On Wed, 2015-08-19 at 19:17 +0000, Grumbach, Emmanuel wrote:
>>>
>>>> Hm.. how would net/core/tso.c avoid this?
>>>
>>> Because a driver using these helpers keep around the original LSO packet
>>> and frees it normally at TX completion time.
>>>
>>
>> Which is why I can't really use it. The complexity is that I have to
>> (ieee802.11 specification) split an LSO is several 802.11 packets. The
>> maximal 802.11 packet I can send under ideal condition is 11K long or
>> so. So I *must* generate several 802.11 frames from one single LSO
>> packet. OTOH, I can have more than MSS bytes in a 802.11 A-MSDU.
>>
> 
> Who said you had to free original packet ? Just keep it around.
> 
> TCP will work better ( check skb_still_in_host_queue() helper if you
> want to know why)

I do keep the original skb: it becomes the first 802.11 packet generated
from that LSO skb. Thing is that it will be freed first and I wanted the
*last packet* to release the pressure on the socket.
So I guess that skb_still_in_host_queue will still find it and avoid
retransmissions at least until the first skb of the LSO is freed.
But unless you are fine with releasing the pressing on the socket as
soon as the *first* 802.11 skb is freed, I need that code.

I'll try to look at dev->gso_max_size that you mentioned below. This can
really be a game changer for me.

> 
>> Maybe what would help would be to be able to dynamically change the
>> maximal size of an LSO packet. That would allow the wifi driver to
>> ensure that the LSO can fit in a single 802.11 packet. Note that since
>> the maximal length of the A-MSDU can vary based on link conditions
>> (since there is only one CRC for the whole A-MSDU, you don't want long
>> A-MSDUs in bad link conditions) the driver would need to be able to tell
>> the TCP stack to modify the length of an LSO packet.
>> To me, this sounds to be ... an overkill?
> 
> It is already doable. Check dev->gso_max_size ( and
> netif_set_gso_max_size())
> 
> Make sure you do not reinvent the wheel ;)
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html