NetMP

new sockbuf

Why do we want to change the sockbuf implementation? Look here.

You can find the new sockbuf code in the 'sockbuf' branch at http://repo.or.cz/w/dragonfly/netmp.git

UPDATE : switched the sockbuf branch to a new semi-lockless sockbuf implementation by Matthew Dillon. Still pondering about a different linked-list implementation (M_CORAL, this is probably only meaningful if you've followed the discussion on irc) without the added indirection through the cupholders.

Cupholder pros:

working code available now
dynamically sized
simple implementation Cupholder cons:
extra memory references
larger cache footprint

M_CORAL pros:

dynamically sized M_CORAL cons:
complex code
maybe issues with deallocating mbufs w/ an attached cluster

Ring buffer pros:

cache efficient
very straightforward code Ring buffer cons:
incurs 8K overhead for every socket (I think I can make it dynamically sized; not sure about code complexity then though)

My plan is to use the cupholder implementation for now and revisit this later. The APIs are largely compatible anyway.

XXX : the rest of this section refers to the ring buffer implementation

If you want to do some testing, you can follow these instructions. Some modules and a few userland utilities don't know about the new sockbuf yet, so please only try to build the kernel as described in the mail above.

Known issues:

nfs occasionally thinks the server has gone down. Recovers almost instantly, but nativekernel time is still affected
http accelerator doesn't even compile
smbfs is probably broken, haven't tested at all
ncp, ipx, Xerox NS are broken; won't fix because: not relevant any more, no users, no way to test (UPDATE: except Jonathan Stuart cares for IPX).
sctp is 'special'. Thomas Nikolajsen volunteered to work on SCTP after the 2.0 release which is just as well, since I don't plan to put in the new sockbuf code until we brach for 2.0
unix domain sockets also not well tested
->rbytes, ->wbytes wraparound not tested
based on a snapshot from May 6th; need to merge with CVS HEAD

Stuff that's expected to work: ftp/http/ssh/nfs/dns/ping

tcpcb

An overview of the problems with accesses to the tcpcb can be found in this message.

Accesses to the tcpcb now always go through the protocol thread. Work started here, was revised later and I fixed the last known bugs shortly afterwards.

UDP inpcb

See the subthread starting here.

socket

Start by reading this mail; needless to say, my analysis was not entirely spotless. Taking into account Matt's suggestions, work has been ongoing in the socket branch in the netmp repo (see above). Also see the rest of the thread. The rest of the socket fields (except ->so_oobmark) are discussed here.