Le 29/01/2019 à 09:42, Jason Thorpe a écrit :
On Jan 29, 2019, at 10:32 AM, Maxime Villard <[email protected]> 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).
