Re: kernel frameworks for jumbo frame

[Maxime Villard <max%m00nbsd.net@localhost>]

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).