Re: Netchannles: first stage has been completed. Further ideas.

[Rusty Russell <rusty@rustcorp.com.au>]

On Thu, 2006-07-27 at 20:33 +0400, Alexey Kuznetsov wrote:
> Hello!
> 
> On Thu, Jul 27, 2006 at 03:46:12PM +1000, Rusty Russell wrote:
> > Of course, it means rewriting all the userspace tools, documentation,
> > and creating a complete new infrastructure for connection tracking and
> > NAT, but if that's what's required, then so be it.
> 
> That's what I love to hear. Not a joke. :-)
> 
> Could I only suggest not to relate this to netchannels? :-)
> In the past we used to call this thing (grand-unified) "flow cache".

Yes.  Thankyou for all your explanation, it was very helpful.  I agree,
grand unified lookup idea returns 8).  Netchannels proposal vs.
netfilter forced me back into thinking about it again, but it is
unrelated.  Any "netfilter bypass" acceleration will want similar ideas.

I apologize for misreading your discussion of Evgeniy's implementation
with general channel problem.  My mistake.  

> > userspace), no dequeue lock is required.
> 
> And that was a part of the second question.
> 
> I do not see, how single threaded TCP is possible. In receiver path
> it has to ack with quite strict time bounds, to delack etc., in sender path
> it has to slow start, I am even not saying about "slow path" things:
> retransmit, probing window, lingering without process context etc.
> It looks like, VJ implies the protocol must be changed. We can't, we mustn't.

All good points.  I can see two kinds of problems here: performance
problems due to wakeup (eg. ack processing for 5MB write), and
correctness problems due to no kernel enforcement.  We need measurements
for the performance issues, so I'll ignore them for the moment.

For correctness, in true end-to-end, kernel is just a router for
userspace, then we do not worry about such problems 8)  In real life
kernel must enforce linger and sending tuple correctness, but I don't
know how much else we must regulate.  Too much, and you are right: we
have slow and fast path split just like now.

> After we deidealize this idealization and recognize that some "slow path"
> should exist and some part of this "slow path" has to be executed
> with higher priority than the "fast" one, where do we arrive?
> Is not it exactly what we have right now? Clean fast path, separate slow path.
> Not good enough? Where? Let's find and fix this.

I am still not sure how significant slow path is: if 99% can be in
userspace, it could work very well for RDMA.  I would like to have seen
VJ's implementation so we could compare and steal bits.

Thanks,
Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law