K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2013-11-04T22:12:25.246702Z
K 7
svn:log
V 2181
Start fleshing out some experimental hacks to start tidying up the
mbuf access in preparation for mbuf iovec support (multiple buffers
per mbuf.)

There are a bunch of fundamental problems:

* There's too much direct access of m_data, m_len, m_pktlen and even
  the underlying buffer (m_pktdat and friends.)  If we're going down
  the path of turning mbufs into iovecs, these need to be tidied up.

* The direct method access of m_data / m_len / etc hides away
  the intent of the action from the actual action itself.
  For example, there's direct gymnastics of m_data to do headroom
  reservation.  There should be an mbuf method that reserves
  an amount of headroom in the mbuf.  Same with allocating tailroom.
  There are also plenty of cases where stuff will "skip" a header
  temporarily by modify m_data / m_len to skip _over_ the header,
  then adjust them back.

* The direct gynmastics with m_len vs m_pktlen is also fraught
  with danger.

* There's lots of hand written mbuf iterators over lists of mbufs
  that represent frames (chained with m_nextpkt) and lists of mbufs
  inside a given frame (chained with m_next.)  This is again
  annoying to diagnose, debug and modify.

So, to make iovec stuff possible:

* The data versus state/flags bits need to be separated out.
  That way the data storage stuff can be optionally turned into
  an array.

* All the direct access of m_data / m_len / m_pkgdat / etc needs to
  go away.  They are now per-buffer versus per-mbuf things.
  Right now that's the same thing, but that does need to change.

* An iterator for mbufs needs to be written and sprinkled around
  the codebase.  Specifically for this particular effort,
  m_next needs to be taken out and shot, replaced with an iterator
  that will iterate over mbufs and then either bump the mbuf data
  index or follow m->m_next to the next mbuf in the chain.

This is still all early days.  I'm going through the exercise
of converting things to methods and killing direct m->m_data access
(which should be mtod() in almost all instances) as part of a general
tidyup that will be good regardless of whether this work goes anywhere
or not.

Sponsored by:	Netflix, Inc.

END