From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [1/1 take 2] Unified socket storage. (with small bench).
Date: Wed, 9 May 2007 13:34:43 +0400 [thread overview]
Message-ID: <20070509093443.GA10028@2ka.mipt.ru> (raw)
In-Reply-To: <20070508.234828.95506666.davem@davemloft.net>
On Tue, May 08, 2007 at 11:48:28PM -0700, David Miller (davem@davemloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Tue, 8 May 2007 21:43:32 +0400
>
> > This is second patch which implements unified cache of sockets for
> > network instead of old hash tables. It stores all types of sockets
> > (although I only implemented af_inet, unix, netlink and raw ones for now)
> > in single object structure called multidimensional trie (which is
> > similar to judy array in some way).
>
> Thanks for doing this work it is very interesting. :)
:) it is interesting indeed.
> > So, this is dynamic structure which can host any kind of network sockets
> > (actually any structure pointer which can be addressed with 160 bits).
> > Structure can be extended to support ipv6 (needs to increase key
> > length) with essentially any number of elements in it.
> >
> > Code is in development stage, but I would like to rise a discussion
> > about needs to continue this development before next steps.
>
> One thing that will need to be adjust for current tree is the UDP
> hashing mechanism. But as far as I can tell your code should be able
> to handle the new scheme (we now hash UDP by saddr+port when
> possible, and this reminds me that IPV6 is broken and needs some
> repairs).
Yes, udp with multicast can be a problem, but it can be solved exactly
the same way I implemented netlink broadcast (simple solution) -
multicast sockets are placed into own list/hash table/trie with special
bit in key/whatever and accessed when needed.
> What exactly does the 'stages' arg mean? Is this a method to handle
> partially bound sockets?
It is a fallback to select a listening socket, which has remote
addr/port as zero, so when socket it selected from tree, lookup wants to
first get established socket with given remote identity and if this
fails, it tries to select a wildcard one.
--
Evgeniy Polyakov
next prev parent reply other threads:[~2007-05-09 9:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-08 17:43 [1/1 take 2] Unified socket storage. (with small bench) Evgeniy Polyakov
2007-05-09 6:48 ` David Miller
2007-05-09 9:34 ` Evgeniy Polyakov [this message]
2007-05-09 9:44 ` David Miller
2007-05-09 9:57 ` Evgeniy Polyakov
2007-05-09 10:02 ` David Miller
2007-05-09 10:22 ` Evgeniy Polyakov
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=20070509093443.GA10028@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=davem@davemloft.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).