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.
working code available now
simple implementation Cupholder cons:
extra memory references
larger cache footprint
dynamically sized M_CORAL cons:
maybe issues with deallocating mbufs w/ an attached cluster
Ring buffer pros:
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.
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
An overview of the problems with accesses to the tcpcb can be found in this message.
See the subthread starting here.
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.