Thread (33 messages) 33 messages, 6 authors, 2012-01-03

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

From: Michał Mirosław <hidden>
Date: 2011-12-22 19:29:51

2011/12/22 David Miller [off-list ref]:
From: Michał Mirosław <redacted>
Date: Thu, 22 Dec 2011 19:34:21 +0100
quoted
2011/12/22 Ian Campbell [off-list ref]:
quoted
On Wed, 2011-12-21 at 19:28 +0000, David Miller wrote:
quoted
From: Eric Dumazet <redacted>
Date: Wed, 21 Dec 2011 15:02:18 +0100
quoted
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?

Best Regards,
Michał Mirosław
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help