[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1349794300.21172.4536.camel@edumazet-glaptop>
Date: Tue, 09 Oct 2012 16:51:40 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ian Campbell <Ian.Campbell@...rix.com>
Cc: Eric Dumazet <edumazet@...gle.com>,
xen-devel <xen-devel@...ts.xen.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Konrad Rzeszutek Wilk <konrad@...nel.org>,
Sander Eikelenboom <linux@...elenboom.it>
Subject: Re: compound skb frag pages appearing in start_xmit
On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> >
> > > Does the higher order pages effectively reduce the number of frags which
> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > > have 64K worth of frag data.
> > >
> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> > > of data, or does the effective maximum number of frags in an skb reduce
> > > to 2?
> >
> > effective number of frags reduce to 2 or 3
> >
> > (We still limit GSO packets to ~63536 bytes)
>
> Great! Then I think the fix is more/less trivial...
>
> As an aside, when the skb head is < 4096 bytes is that necessarily a
> compound page or might it just be a large kmalloc area?
>
skb->head can be either allocated by kmalloc() (standard alloc_skb()) or
a page frag (if allocated in rx path)
Not sure its related to headlen/size...
--
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