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

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

From: Eric Dumazet <hidden>
Date: 2011-12-21 11:08:47

Le mercredi 21 décembre 2011 à 11:03 +0000, Ian Campbell a écrit :
On Fri, 2011-12-09 at 18:34 +0000, David Miller wrote:
quoted
From: Ian Campbell <redacted>
Date: Fri, 9 Dec 2011 13:47:07 +0000
quoted
If we had a concept like MAX_SKB_PAGES then it would perhaps make
sense to have + 2 there, but AFAICT drivers etc are already
accounting for this appropriately by adding a further + 2 (or
sometimes + 1) to MAX_SKB_FRAGS.
Any kind of code like this, including the "+ 2" in the skbuff header,
should be coded to use some kind of macro so we can track this
dependency instead of stumbling onto it and accidently breaking lots
of stuff if we want to change this "2" value.
Agreed.

Part of the problem is that no one seems to have any idea what this
particular + 2 means. My best hypothesis is that it accounts for the
pages used by the linear area (which potentially crosses a page
boundary).
I dont understand the point.

linear data is allocated with kmalloc(), so technically speaking its
located in a single page, but page order can be 0, 1, 2, 3, ...
MAX_ORDER.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help