docs/developer/NetMP.mdwn

   1 # NetMP \r
   2 \r
   3 [What's this all about?](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-04/msg00093.html)\r
   4 \r
   5 ## new sockbuf \r
   6 \r
   7 Why do we want to change the sockbuf implementation? Look [here](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-05/msg00003.html).\r
   8 \r
   9 You can find the new sockbuf code in the 'sockbuf' branch at http://repo.or.cz/w/dragonfly/netmp.git\r
  10 \r
  11  **UPDATE** : switched the sockbuf branch to a new semi-lockless sockbuf implementation\r
  12 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.\r
  13 \r
  14 Cupholder pros:\r
  15
  16 * working code available now\r
  17
  18 * dynamically sized\r
  19
  20 * simple implementation\r
  21 Cupholder cons:\r
  22
  23 * extra memory references\r
  24
  25 * larger cache footprint\r
  26 \r
  27 M_CORAL pros:\r
  28
  29 * dynamically sized\r
  30 M_CORAL cons:\r
  31
  32 * complex code\r
  33
  34 * maybe issues with deallocating mbufs w/ an attached cluster\r
  35 \r
  36 Ring buffer pros:\r
  37
  38 * cache efficient\r
  39
  40 * very straightforward code\r
  41 Ring buffer cons:\r
  42
  43 * incurs 8K overhead for every socket (I think I can make it dynamically sized; not sure about code complexity then though)\r
  44 \r
  45 My plan is to use the cupholder implementation for now and revisit this later. The APIs are\r
  46 largely compatible anyway.\r
  47 \r
  48  **XXX** : the rest of this section refers to the ring buffer implementation\r
  49 \r
  50 If you want to do some testing, you can follow [these instructions](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-06/msg00085.html). \r
  51 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.\r
  52 \r
  53 Known issues:\r
  54
  55 * nfs occasionally thinks the server has gone down. Recovers almost instantly, but nativekernel time is still affected\r
  56
  57 * http accelerator doesn't even compile\r
  58
  59 * smbfs is probably broken, haven't tested at all\r
  60
  61 * 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](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-06/msg00113.html) for IPX).\r
  62
  63 * sctp is 'special'. Thomas Nikolajsen [volunteered](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-06/msg00121.html) 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\r
  64
  65 * unix domain sockets also not well tested\r
  66
  67 * ->rbytes, ->wbytes wraparound not tested\r
  68
  69 * based on a snapshot from May 6th; need to merge with CVS HEAD\r
  70 \r
  71 Stuff that's expected to work:\r
  72 ftp/http/ssh/nfs/dns/ping\r
  73 \r
  74 ## tcpcb \r
  75 An overview of the problems with accesses to the tcpcb can be found in [this](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-06/msg00055.html) message.\r
  76 \r
  77 Accesses to the tcpcb now always go through the protocol thread. Work started [here](http://leaf.dragonflybsd.org/mailarchive/commits/2008-06/msg00123.html), was revised\r
  78 [later](http://leaf.dragonflybsd.org/mailarchive/commits/2008-07/msg00055.html) and I [fixed](http://leaf.dragonflybsd.org/mailarchive/commits/2008-07/msg00104.html) the last\r
  79 known bugs shortly afterwards.\r
  80 \r
  81 ## UDP inpcb \r
  82 See the subthread starting [here](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-06/msg00057.html).\r
  83 \r
  84 ## socket \r
  85 \r
  86 Start by reading [this](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-08/msg00037.html) mail; needless to say, my analysis was not entirely spotless. Taking into account Matt's [suggestions](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-08/msg00040.html), 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](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-08/msg00065.html).\r