Date: Mon, 6 Mar 2006 19:42:37 -0500
From: Benjamin LaHaise <bcrl@kvack.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: drepper@gmail.com, da-x@monatomic.org, linux-kernel@vger.kernel.org
Subject: Re: Status of AIO
Message-ID: <20060307004237.GT20768@kvack.org>
References: <20060306211854.GM20768@kvack.org> <a36005b50603061453w36f5d49cs7bac0c186aee30b3@mail.gmail.com> <20060306233300.GR20768@kvack.org> <20060306.162444.107249907.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060306.162444.107249907.davem@davemloft.net>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1935
Lines: 40

On Mon, Mar 06, 2006 at 04:24:44PM -0800, David S. Miller wrote:
> > Oh?  I've always envisioned that network AIO would be able to use O_DIRECT 
> > style zero copy transmit, and something like I/O AT on the receive side.  
> > The in kernel API provides a lightweight event mechanism that should work 
> > ideally for this purpose.
> 
> I think something like net channels will be more effective on receive.

Perhaps, but we don't necessarily have to go to that extreme to get the 
value of the approach.  One way of doing network receive that would let 
us keep the same userland API is to have the kernel perform the receive 
portion of TCP processing in userspace as a vsyscall.  The whole channel 
would then be a concept internal to the kernel.  Once that works and the 
internals have settled down, it might make sense to export an API that 
allows us to expose parts of the channel to the user.

Unfortunately, I think that the problem of getting the packets delivered 
to the right user is Hard (especially with incoming filters and all the 
other features of the stack).

...
> I want a bonafide networking person to work on any high performance
> networking API we every decide to actually use.

I'm open to suggestions. =-)  So far my thoughts have mostly been limited 
to how to make tx faster, at which point you have to go into the kernel 
somehow to deal with the virtual => physical address translation (be it 
with a locked buffer or whatever) and kicking the hardware.  Rx has been 
much less interesting simply because the hardware side doesn't offer as 
much.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/