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". > I don't think they are equivalent. In channels, I understand this. Actually, it was what I said in the next paragraph, which you even cited. I really do not like to repeat myself, it is nothing but idle talk, but if the questions are questioned... First, it was stated that suggested implementation performs better and even much better. I am asking why do we see such improvement? I am absolutely not satisifed with statement "It is better. Period." >From all that I see, this particular implementation does not implement optimizations suggested by VJ, it implements only the things, which are not supposed to affect performance or to affect it negatively. Idle talk? I am sure that if that improvement happened not due to a severe protocol violation we can easily fix existing stack. > 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. 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. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
