Re: [PATCH 0/4] skb paged fragment destructors

[David Miller <davem@davemloft.net>]

From: Michał Mirosław <mirqus@gmail.com>
Date: Thu, 22 Dec 2011 20:29:30 +0100

> 2011/12/22 David Miller <davem@davemloft.net>:
>> From: Michał Mirosław <mirqus@gmail.com>
>> Date: Thu, 22 Dec 2011 19:34:21 +0100
>>
>>> 2011/12/22 Ian Campbell <Ian.Campbell@citrix.com>:
>>>> On Wed, 2011-12-21 at 19:28 +0000, David Miller wrote:
>>>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>>>> Date: Wed, 21 Dec 2011 15:02:18 +0100
>>>>> > No idea on this +2 point.
>>>>> I think I know, and I believe I instructed Alexey Kuznetsov to do
>>>>> this.
>>>>>
>>>>> When sendfile() is performed, we might start the SKB with the last few
>>>>> bytes of one page, and end the SKB with the first few bytes of another
>>>>> page.
>>>>>
>>>>> In order to fit a full 64K frame into an SKB in this situation we have
>>>>> to accomodate this case.
>>>> Thanks David, that makes sense.
>>>>
>>>> However I think you only actually need 1 extra page for that. If the
>>>> data in frag[0] starts at $offset then frag[16] will need to have
>>>> $offset bytes in it. e.g.
>>>>        4096-$offset + 4096*15 + $offset = 65536
>>>> which == 17 pages rather than 18.
>>>>
>>>> The following documents the status quo but I could update to switch to +
>>>> 1 instead if there are no flaws in the above logic...
>>>
>>> Since max IP datagram is 64K-1, adding ethernet and possibly VLAN
>>> headers makes the max size slightly above 64K and then you have
>>> 64K/PAGE_SIZE+2 pages appear in worst case.
>>
>> Headers go into the linear area, so they are not relevant for these
>> calculations.
> 
> Does this hold for LRO'ed packets and packets sent via PF_PACKET socket?

LRO is for receive, not packets we build on transmit, and in any event
have their headers also pulled into the linear area before the stack
sees it.

For PF_PACKET, in the packet_snd() case it uses a linear SKB and in
the tpacket_snd() case it uses a linear SKB as well.