[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090130215920.GC31355@1wt.eu>
Date: Fri, 30 Jan 2009 22:59:20 +0100
From: Willy Tarreau <w@....eu>
To: David Miller <davem@...emloft.net>
Cc: jarkao2@...il.com, zbr@...emap.net, herbert@...dor.apana.org.au,
dada1@...mosbay.com, ben@...s.com, mingo@...e.hu,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
jens.axboe@...cle.com
Subject: Re: [PATCH v2] tcp: splice as many packets as possible at once
On Fri, Jan 30, 2009 at 01:42:27PM -0800, David Miller wrote:
> From: Jarek Poplawski <jarkao2@...il.com>
> Date: Tue, 27 Jan 2009 07:40:48 +0000
>
> > I think the main problem is to respect put_page() more, and maybe you
> > mean to add this to your allocator too, but using slab pages for this
> > looks a bit complex to me, but I can miss something.
>
> Hmmm, Jarek's comments here made me realize that we might be
> able to do some hack with cooperation with SLAB.
>
> Basically the idea is that if the page count of a SLAB page
> is greater than one, SLAB will not use that page for new
> allocations.
I thought it was the standard behaviour. That may explain why I
did not understand much of previous discussion then :-/
> It's cheesy and the SLAB developers will likely barf at the
> idea, but it would certainly work.
Maybe that would be enough as a definitive fix for a stable
release, so that we can go on with deeper changes in newer
versions ?
> Back to real life, I think long term the thing to do is to just do the
> cached page allocator thing we'll be doing after Jarek's socket page
> patch is integrated, and for best performance the driver has to
> receive it's data into pages, only explicitly pulling the ethernet
> header into the linear area, like NIU does.
Are there NICs out there able to do that themselves or does the
driver need to rely on complex hacks in order to achieve this ?
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists