DragonFly kernel List (threaded) for 2008-08
Re: [netmp] socket accesses
On Saturday 09 August 2008, Matthew Dillon wrote:
> 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.
> :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.
> :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!),
> :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?
> I think so_incomp is just used on listening sockets, right? Protecting
> it with a spinlock is probably just fine.
For now :)
> 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".
> 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:
> If you haven't been paying attention, see here too
Which will point you to
You can use the web interface at
to browse the code or try
git clone git://repo.or.cz/dragonfly/netmp.git
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.