[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1324465724.2728.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Wed, 21 Dec 2011 12:08:44 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ian Campbell <Ian.Campbell@...rix.com>
Cc: David Miller <davem@...emloft.net>,
"jesse.brandeburg@...el.com" <jesse.brandeburg@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/4] skb paged fragment destructors
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:
> > From: Ian Campbell <Ian.Campbell@...rix.com>
> > Date: Fri, 9 Dec 2011 13:47:07 +0000
> >
> > > 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.
--
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
Powered by blists - more mailing lists