[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39e6f6c70705040707l4556347akb5d5d8fe9282c041@mail.gmail.com>
Date: Fri, 4 May 2007 11:07:12 -0300
From: "Arnaldo Carvalho de Melo" <acme@...stprotocols.net>
To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
netdev@...r.kernel.org,
"Trond Myklebust" <trond.myklebust@....uio.no>,
"Thomas Graf" <tgraf@...g.ch>,
"David Miller" <davem@...emloft.net>,
"James Bottomley" <James.Bottomley@...eleye.com>,
"Mike Christie" <michaelc@...wisc.edu>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Daniel Phillips" <phillips@...gle.com>
Subject: Re: [PATCH 16/40] netvm: hook skb allocation to reserves
On 5/4/07, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> Change the skb allocation api to indicate RX usage and use this to fall back to
> the reserve when needed. Skbs allocated from the reserve are tagged in
> skb->emergency.
>
> Teach all other skb ops about emergency skbs and the reserve accounting.
>
> Use the (new) packet split API to allocate and track fragment pages from the
> emergency reserve. Do this using an atomic counter in page->index. This is
> needed because the fragments have a different sharing semantic than that
> indicated by skb_shinfo()->dataref.
>
> (NOTE the extra atomic overhead is only for those pages allocated from the
> reserves - it does not affect the normal fast path.)
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> ---
> include/linux/skbuff.h | 22 +++++-
> net/core/skbuff.c | 161 ++++++++++++++++++++++++++++++++++++++++++-------
> 2 files changed, 157 insertions(+), 26 deletions(-)
>
> +#define skb_alloc_rx(skb) (skb_emergency(skb) ? SKB_ALLOC_RX : 0)
skb_alloc_rx seems to imply "alloc an skb for rx", not "gimme the
right flags to allocate a skb for rx". Can this be changed to
"skb_alloc_rx_flag(skb)", similar to the existing sock_flag() for
socks?
- Arnaldo
-
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