Re: kernel frameworks for jumbo frame

[Jason Thorpe <thorpej%me.com@localhost>]

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

One thing that is worth considering in all of this is what the MMU page size is on the system.  It might be advantageous, for example, to allocate 4x 4K external buffers rather than a single 16K external buffer, because then on a direct-map system, you can utilize ext_paddr and save the work of extracting the physical addresses when it's time load the DMA map.

-- thorpej