tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kernel frameworks for jumbo frame



Le 29/01/2019 à 09:42, Jason Thorpe a écrit :
On Jan 29, 2019, at 10:32 AM, Maxime Villard <max%m00nbsd.net@localhost> wrote:

- As you said, we have only one cluster size to begin with.
- MEXTMALLOC is here to allocate variable-sized clusters, but it is
  really ugly and should be removed. Same for MEXTADD.
- The error handling of MCLGET() is error-prone.
- The naming of certain functions is confusing, like m_getcl, which
  is one typo away from m_clget.

MEXTMALLOC() should probably go away, yes.  However, MEXTADD() and the whole
set of "arbitrary external storage" has the potential to be quite useful.
Back in the day, I used it to implement a zero-copy data path from
disk-to-network in an iSCSI storage appliance.  I know that the sosend_loan
stuff has been disabled for a while, but I think it's worth keeping the
infrastructure that enables it around.

Now, if you're just talking about removing MEXTADD() itself, but keeping the
underlying _m_ext_storage infrastructure, fine.

The main reason why I don't like MEXTADD is that the 'ext_free' field of
_m_ext_storage is in charge of freeing the mbuf itself, and not just its
storage. Because of that we have to make 'mb_cache' public, and it is now
hanging around in several drivers. In terms of abstraction, this is bad.
In terms of diagnostic checks, too, because the drivers don't set MT_FREE
and m_data to NULL.

But anyway, we can keep MEXTADD and just fix that (and also rename it).


Home | Main Index | Thread Index | Old Index