On Wed, 2011-12-21 at 11:08 +0000, Eric Dumazet wrote:

Le mercredi 21 décembre 2011 à 11:03 +0000, Ian Campbell a écrit :

quoted

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.

I did say hypothesis ;-) Do you know what that + 2 is actually all
about?

If no one knows what it is for maybe we should just remove it directly
instead of what I proposed?

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.

I think I must misunderstand the terminology.

An order 1 allocation is in multiples of PAGE_SIZE, isn't it, even
though they happen to be contiguous?

Or are you considering the possibility of kmalloc returning a super page
of some description? Isn't that to some extent transparent to the caller
who (assuming PAGE_SIZE 4096) doesn't know if kmalloc(16384) returned
4*4096 contiguous pages or 1*16384 page?

Anyway I take your underlying point that 2*PAGE_SIZE is no kind of limit
on the size of the linear region.

Ian.