From: Rusty Russell [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 15:54:04 +1000
(1) I am imagining some Grand Unified Flow Cache (Olsson trie?) that
holds (some subset of?) flows. A successful lookup immediately after
packet comes off NIC gives destiny for packet: what route, (optionally)
what
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 27 Jul 2006 11:54:19 -0700
I think we sell our existing stack short.
I agree.
There are lots of opportunities left to look more closely at actual
real performance bottlenecks and improve incrementally. But it
requires, tools, time, faster
From: Rusty Russell [EMAIL PROTECTED]
Date: Thu, 27 Jul 2006 15:46:12 +1000
Yes, my first thought back in January was how netfilter would interact
with this in a sane way. One answer is don't: once someone registers
on any hook we go into slow path. Another is to run the hooks in socket
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
Hello, Alexey.
On Thu, Jul 27, 2006 at 08:33:35PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
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.
On Wed, 26 Jul 2006 23:00:28 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Rusty Russell [EMAIL PROTECTED]
Date: Thu, 27 Jul 2006 15:46:12 +1000
Yes, my first thought back in January was how netfilter would interact
with this in a sane way. One answer is don't: once someone
Hello!
kernel thread takes 100% cpu (with preemption
Preemption, you tell... :-)
I begged you to spend 1 minute of your time to press ^Z. Did you?
Alexey
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
On Fri, Jul 28, 2006 at 12:56:51AM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
Hello!
kernel thread takes 100% cpu (with preemption
Preemption, you tell... :-)
I begged you to spend 1 minute of your time to press ^Z. Did you?
What would you expect from non-preemptible kernel?
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 09:17:25 +0400
What would you expect from non-preemptible kernel? Hard lockup, no acks,
no soft irqs.
Why does pressing Ctrl-Z on the user process stop kernel soft irq
processing?
-
To unsubscribe from this list: send the line
On Thu, Jul 27, 2006 at 10:34:00PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 09:17:25 +0400
What would you expect from non-preemptible kernel? Hard lockup, no acks,
no soft irqs.
Why does pressing Ctrl-Z on the user
On Wed, 2006-07-26 at 23:00 -0700, David Miller wrote:
From: Rusty Russell [EMAIL PROTECTED]
Date: Thu, 27 Jul 2006 15:46:12 +1000
Yes, my first thought back in January was how netfilter would interact
with this in a sane way. One answer is don't: once someone registers
on any hook we
On Wed, 2006-07-19 at 03:01 +0400, Alexey Kuznetsov wrote:
Hello!
Can I ask couple of questions? Just as a person who looked at VJ's
slides once and was confused. And startled, when found that it is not
considered as another joke of genuis. :-)
Hi Alexey!
About locks:
is
From: Rusty Russell [EMAIL PROTECTED]
Date: Thu, 27 Jul 2006 12:17:51 +1000
On Wed, 2006-07-19 at 03:01 +0400, Alexey Kuznetsov wrote:
About locks:
is completely lockless (there is one irq lock when skb
is queued/dequeued into netchannels queue in hard/soft irq,
Equivalent
On Wed, 2006-07-26 at 22:17 -0700, David Miller wrote:
I read this as we will be able to get around the problems but
no specific answer as to how. I am an optimist too but I want
to start seeing concrete discussion about the way in which the
problems will be dealt with.
Alexey has some
On Wed, 19 Jul 2006 13:01:50 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 19 Jul 2006 15:52:04 -0400
As a related note, I am looking into fixing inet hash tables to use RCU.
IBM had posted a patch a long time ago, which would be
Hello!
Also, there is some code for refcnt's in it that looks wrong.
Yes, it is disgusting. rcu does not allow to increase socket refcnt
in lookup routine.
Ben's version looks cleaner here, it does not touch refcnt
in rcu lookups. But it is dubious too:
do_time_wait:
+ sock_hold(sk);
[EMAIL PROTECTED] wrote:
Evgeniy Polyakov wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear
([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am
On Thu, Jul 20, 2006 at 09:55:04PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 02:59:08 +0400
Moving protocol (no matter if it is TCP or not) closer to user allows
naturally control the dataflow - when user can read that
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path routing
logic...)
I do
On Fri, Jul 21, 2006 at 11:19:00AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED])
wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for
On Fri, Jul 21, 2006 at 09:40:32AM +1200, Ian McDonald ([EMAIL PROTECTED])
wrote:
If we consider netchannels as how Van Jackobson discribed them, then
mutext is not needed, since it is impossible to have several readers or
writers. But in socket case even if there is only one userspace
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 11:10:10 +0400
On Thu, Jul 20, 2006 at 09:55:04PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
Correct, and too large delay even results in retransmits. You can say
that RTT will be adjusted by delay of ACK, but if user
On Fri, Jul 21, 2006 at 12:47:13AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
Correct, and too large delay even results in retransmits. You can say
that RTT will be adjusted by delay of ACK, but if user context
switches cleanly at the beginning, resulting in near immediate ACKs,
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:06:11 +0400
Receiving side, nor matter if it is socket or netchannel, will drop
packets (socket due to queue overfull, netchannels will not drop, but
will not ack (it's maximum queue len is 1mb)).
So both approaches behave
On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:06:11 +0400
Receiving side, nor matter if it is socket or netchannel, will drop
packets (socket due to queue overfull, netchannels will not
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:39:09 +0400
On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:06:11 +0400
Receiving side, nor matter if it is socket
Evgeniy Polyakov wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path
All this talk reminds me of one thing, how expensive tcp_ack() is.
And this expense has nothing to do with TCP really. The main cost is
purging and freeing up the skbs which have been ACK'd in the
retransmit queue.
So tcp_ack() sort of inherits the cost of freeing a bunch of SKBs
which haven't
On Fri, Jul 21, 2006 at 09:14:39AM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path routing
logic...)
I do
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 09:26:42 -0700
All this talk reminds me of one thing, how expensive tcp_ack() is.
And this expense has nothing to do with TCP really. The main cost is
purging and freeing up the skbs which have been ACK'd in the
retransmit queue.
Hello!
Hello, Alexey.
[ Sorry for long delay, there are some problems with mail servers, so I
can not access them remotely, so I create mail by hads, hopefully thread
will not be broken. ]
There is no socket spinlock anymore.
Above lock is skb_queue lock which is held inside
Hello.
[ Sorry for long delay, there are some problems with mail servers, so I
can not access them remotely, so I create mail by hads, hopefully thread
will not be broken. ]
Your description makes it sound as if you would take a huge leap,
changing all in-kernel code _and_ the userspace
Hello!
Small question first:
userspace, but also there are big problems, like one syscall per ack,
I do not see redundant syscalls. Is not it expected to send ACKs only
after receiving data as you said? What is the problem?
Now boring things:
There is no BH protocol processing at all, so
On Thu, Jul 20, 2006 at 08:41:00PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
Hello!
Hello, Alexey.
Small question first:
userspace, but also there are big problems, like one syscall per ack,
I do not see redundant syscalls. Is not it expected to send ACKs only
after receiving
Evgeniy Polyakov wrote:
Backlog is actually not a protection, but a thing equivalent to netchannel.
The difference is only that it tries to process something immediately,
when it is safe. You can omit this and push everything to backlog(=netchannel),
which is processed only by syscalls, if you
If we consider netchannels as how Van Jackobson discribed them, then
mutext is not needed, since it is impossible to have several readers or
writers. But in socket case even if there is only one userspace
consumer, that lock must be held to protect against bh (or introduce
several queues and
Hello!
Moving protocol (no matter if it is TCP or not) closer to user allows
naturally control the dataflow - when user can read that data(and _this_
is the main goal), user acks, when it can not - it does not generate
ack. In theory
To all that I rememeber, in theory absence of feedback
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 02:59:08 +0400
Moving protocol (no matter if it is TCP or not) closer to user allows
naturally control the dataflow - when user can read that data(and _this_
is the main goal), user acks, when it can not - it does not generate
On Tue, 18 July 2006 23:08:01 +0400, Evgeniy Polyakov wrote:
On Tue, Jul 18, 2006 at 02:15:17PM +0200, J?rn Engel ([EMAIL PROTECTED])
wrote:
Your description makes it sound as if you would take a huge leap,
changing all in-kernel code _and_ the userspace interface in a single
patch.
Hello!
There is no socket spinlock anymore.
Above lock is skb_queue lock which is held inside
skb_dequeue/skb_queue_tail calls.
Lock is named differently, but it is still here.
BTW for UDP even the name is the same.
Equivalent of socket user lock.
No, it is an equivalent for hash lock
As a related note, I am looking into fixing inet hash tables to use RCU.
-
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
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 19 Jul 2006 15:52:04 -0400
As a related note, I am looking into fixing inet hash tables to use RCU.
IBM had posted a patch a long time ago, which would be not
so hard to munge into the current tree. See if you can
spot it in the archives :)
On Wed, 19 Jul 2006 13:01:50 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 19 Jul 2006 15:52:04 -0400
As a related note, I am looking into fixing inet hash tables to use RCU.
IBM had posted a patch a long time ago, which would be
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 18 Jul 2006 12:16:26 +0400
I would ask to push netchannel support into -mm tree, but I expect
in advance that having two separate TCP stacks (one of which can
contain some bugs (I mean atcp.c)) is not that good idea, so I
understand possible
On Tue, Jul 18, 2006 at 01:34:37AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
Perhaps I am mistaken with my priorities, but I tend to hit all the
easy patches and bug fixes first, before significant new work.
And even in the realm of new work, your things require the most
serious
Hello Evgeniy,
+asmlinkage long sys_netchannel_control(void __user *arg)
[...]
+ if (copy_from_user(ctl, arg, sizeof(struct unetchannel_control)))
+ return -ERESTARTSYS;
^^^
[...]
+ if (copy_to_user(arg, ctl, sizeof(struct
On Tue, Jul 18, 2006 at 01:16:18PM +0200, Christian Borntraeger ([EMAIL
PROTECTED]) wrote:
Hello Evgeniy,
+asmlinkage long sys_netchannel_control(void __user *arg)
[...]
+ if (copy_from_user(ctl, arg, sizeof(struct unetchannel_control)))
+ return -ERESTARTSYS;
On Tue, 18 July 2006 12:16:26 +0400, Evgeniy Polyakov wrote:
Current tests with the latest netchannel patch show that netchannels
outperforms sockets in any type of bulk transfer (big-sized, small-sized,
sending, receiving) over 1gb wire. I omit graphs and numbers here,
since I posted it
On Tuesday 18 July 2006 13:51, Evgeniy Polyakov wrote:
I think this should be -EFAULT instead of -ERESTARTSYS, right?
I have no strong feeling on what must be returned in that case.
As far as I see, copy*user can fail due to absence of the next
destination page, so -ERESTARTSYS makes sence,
On Tue, Jul 18, 2006 at 02:15:17PM +0200, J?rn Engel ([EMAIL PROTECTED]) wrote:
Your description makes it sound as if you would take a huge leap,
changing all in-kernel code _and_ the userspace interface in a single
patch. Am I wrong? Or am I right and would it make sense to extract
small
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 18 Jul 2006 23:11:37 +0400
Actually userspace will not see ERESTARTSYS, when it is returned from
syscall.
This is true only when a signal is pending.
It is the signal dispatch code that fixes up the return value
either by changing it to
Hello!
Can I ask couple of questions? Just as a person who looked at VJ's
slides once and was confused. And startled, when found that it is not
considered as another joke of genuis. :-)
About locks:
is completely lockless (there is one irq lock when skb
is queued/dequeued into
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Wed, 19 Jul 2006 03:01:21 +0400
The only improvement in this area suggested in VJ's slides is a
lock-free producer-consumer ring. It is missing in your patch and I
could guess it is not big loss, it is unlikely to improve something
significantly
On Wed, Jul 19, 2006 at 03:01:21AM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
Hello!
Hello, Alexey.
Can I ask couple of questions? Just as a person who looked at VJ's
slides once and was confused. And startled, when found that it is not
considered as another joke of genuis. :-)
55 matches
Mail list logo
