All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.