On Saturday 09 August 2008, Matthew Dillon wrote:
[...]
quoted text
>     Ok, here are my suggestions:
[...]
I think I'm going to postpone answering to your suggestions until I start
writing the relevant code (that would be ASAP), so that we can talk specifics.

quoted text
> :WRT SS_NOFDREF:
> :
> :- it is set on error by socreate(), but at this point the socket is not
> :  reachable yet
> :...
> :So, unless I'm missing something, SS_NOFDREF is only modified before the socket
> :becomes relevant or after the socket is no longer reachable.
> 
>     Not sure about this one.

I'm going to recheck that.

quoted text
> :Moving to so_incomp:
> :
> :it's modified by sofree() (only called by protocol thread), sonewconn (same) and
> :soisconnected(). The latter is called from process context (fifo_open,
> :portal_connect at least, maybe sctp too) and from the bluetooth netisr.
> :
> :->so_comp is modified by soclose (called from process context), soisconnected,
> :sonewconn (see above), soaccept_predicate, sctp_get_peeloff (of course!),
> :ng_ksocket_finish_accept().
> :
> :Assuming we can move all list modification in protocol thread context, the
> :list traversal would still be tricky. Maybe a spinlock protecting the lists and
> :queue lengths is in order for now? The same lock could be reused for protecting
> :SS_INCOMP, SS_COMP. In the future we might try something more clever if this
> :becomes a performance issue. Opinions?
[...]
quoted text
>     I think so_incomp is just used on listening sockets, right?  Protecting
>     it with a spinlock is probably just fine.

For now :)

quoted text
>     The so_state flags themselves would have to be set and cleared with
>     atomic ops.  Any situation which requires notifying the protocol stack,
>     such as when userland sets CANTRCVMORE, can be done with a 'checkstate'
>     style message to the protocol stack.  The message would not contain the
>     flag, userland would simply set the flag and then tell the protocol
>     stack to check its flags state and do whatever needs to be done.

Not sure how to decide "what needs to be done".

quoted text
>     How about read()/write()/send()/recv()/etc?  That is, so_rcvbuf and
>     so_sndbuf operation?  I'm thinking the mbuf chains are going to have
>     to be protected with a lock of some sort.  It seems like it should work,
>     except when an mbuf must be split up... I think even that could be made
>     to work if the new mbuf is pre-allocated/pre-cached so the split can
>     occur inside the spinlock protection.

Quoting my self:
quoted text
> If you haven't been paying attention, see here too
>
> http://wiki.dragonflybsd.org/index.cgi/NetMP

Which will point you to
http://leaf.dragonflybsd.org/mailarchive/kernel/2008-05/msg00003.html
and
http://leaf.dragonflybsd.org/mailarchive/kernel/2008-06/msg00085.html

You can use the web interface at
http://repo.or.cz/w/dragonfly/netmp.git?a=shortlog;h=refs/heads/sockbuf
to browse the code or try

git clone git://repo.or.cz/dragonfly/netmp.git
cd netmp
git branch sockbuf origin/sockbuf
git checkout sockbuf

to get an on-disk copy. The code needs a simplification pass, but mostly
works now (known issues at http://wiki.dragonflybsd.org/index.cgi/NetMP).
That should take care of the so_rcvbuf, so_sndbuf issues.

Aggelos