From: Rusty Russell <rusty@rustcorp.com.au>
To: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: Re: Netchannles: first stage has been completed. Further ideas.
Date: Thu, 27 Jul 2006 12:17:51 +1000 [thread overview]
Message-ID: <1153966671.6904.71.camel@localhost.localdomain> (raw)
In-Reply-To: <20060718230121.GA31474@ms2.inr.ac.ru>
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 completely lockless (there is one irq lock when skb
> > is queued/dequeued into netchannels queue in hard/soft irq,
>
> Equivalent of socket spinlock.
I don't think they are equivalent. In channels, this can be split into
two locks, queue lock and an dequeue lock, which operate independently.
The socket spinlock cannot. Moreover, in the case where there is a
guarantee about IRQs being bound to a single CPU (as Dave's ideas on
MSI), the queue lock is no longer required. In the case where there is
a single reader of the socket (or, as VJ did, the other end is in
userspace), no dequeue lock is required.
> VJ slides describe a totally different scheme, where softirq part is omitted
> completely, protocol processing is moved to user space as whole.
> It is an amazing toy. But I see nothing, which could promote its status
> to practical. Exokernels used to do this thing for ages, and all the
> performance gains are compensated by overcomplicated classification
> engine, which has to remain in kernel and essentially to do the same
> work which routing/firewalling/socket hash tables do.
My feeling is that modern cards will do partial demux for us; whether we
use netchannels or not, we should use that to accelerate lookup. Making
card aim MSI at same CPU for same flow is a start (and as Dave said,
much less code). As the next step, having the card give us a cookie
too, would allow us to explicitly skip first level of lookup. This
should allow us to identify which flows are simple enough to be directly
accelerated (whether by channels or something else): no bonding, raw
sockets, non-trivial netfilter rules, connection tracking changes, etc.
Thoughts?
Rusty.
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
next prev parent reply other threads:[~2006-07-27 2:17 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-18 8:16 Netchannles: first stage has been completed. Further ideas Evgeniy Polyakov
2006-07-18 8:34 ` David Miller
2006-07-18 8:50 ` Evgeniy Polyakov
2006-07-18 11:16 ` Christian Borntraeger
2006-07-18 11:51 ` Evgeniy Polyakov
2006-07-18 12:36 ` Christian Borntraeger
2006-07-18 19:11 ` Evgeniy Polyakov
2006-07-18 21:20 ` David Miller
2006-07-18 12:15 ` Jörn Engel
2006-07-18 19:08 ` Evgeniy Polyakov
2006-07-19 11:00 ` Jörn Engel
2006-07-20 7:42 ` Evgeniy Polyakov
2006-07-18 23:01 ` Alexey Kuznetsov
2006-07-19 0:39 ` David Miller
2006-07-19 5:38 ` Evgeniy Polyakov
2006-07-19 6:30 ` Evgeniy Polyakov
2006-07-19 13:19 ` Alexey Kuznetsov
2006-07-20 7:32 ` Evgeniy Polyakov
2006-07-20 16:41 ` Alexey Kuznetsov
2006-07-20 21:08 ` Evgeniy Polyakov
2006-07-20 21:21 ` Ben Greear
2006-07-21 7:19 ` Evgeniy Polyakov
2006-07-21 7:20 ` Evgeniy Polyakov
2006-07-21 16:14 ` Ben Greear
2006-07-21 16:27 ` Evgeniy Polyakov
2006-07-22 13:23 ` Caitlin Bestler
2006-07-20 21:40 ` Ian McDonald
2006-07-21 7:26 ` Evgeniy Polyakov
2006-07-20 22:59 ` Alexey Kuznetsov
2006-07-21 4:55 ` David Miller
2006-07-21 7:10 ` Evgeniy Polyakov
2006-07-21 7:47 ` David Miller
2006-07-21 9:06 ` Evgeniy Polyakov
2006-07-21 9:19 ` David Miller
2006-07-21 9:39 ` Evgeniy Polyakov
2006-07-21 9:46 ` David Miller
2006-07-21 9:55 ` Evgeniy Polyakov
2006-07-21 16:26 ` Rick Jones
2006-07-21 20:57 ` David Miller
2006-07-19 19:52 ` Stephen Hemminger
2006-07-19 20:01 ` David Miller
2006-07-19 20:16 ` Stephen Hemminger
2006-07-24 18:54 ` Stephen Hemminger
2006-07-24 20:52 ` Alexey Kuznetsov
2006-07-27 2:17 ` Rusty Russell [this message]
2006-07-27 5:17 ` David Miller
2006-07-27 5:46 ` Rusty Russell
2006-07-27 6:00 ` David Miller
2006-07-27 18:54 ` Stephen Hemminger
2006-07-28 8:21 ` David Miller
2006-07-28 5:54 ` Rusty Russell
2006-08-01 4:47 ` David Miller
2006-08-01 6:36 ` Rusty Russell
2006-07-27 16:33 ` Alexey Kuznetsov
2006-07-27 16:51 ` Evgeniy Polyakov
2006-07-27 20:56 ` Alexey Kuznetsov
2006-07-28 5:17 ` Evgeniy Polyakov
2006-07-28 5:34 ` David Miller
2006-07-28 5:47 ` Evgeniy Polyakov
2006-07-28 4:49 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1153966671.6904.71.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=davem@davemloft.net \
--cc=johnpol@2ka.mipt.ru \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.