Re: RFC: overheads of using mb_unmapped_to_ext?

On Sat, May 9, 2026 at 3:43 PM Rick Macklem <[email protected]> wrote:
>
> Hi,
>
> I have a simple patch that makes the NFS server generate
> read replies as a list of m_extpg mbufs. (The code already
> knows how to do this for the KTLS, but this patch enables
> it for non-TLS use.)
>
> I am wondering if the overhead of calling
> mb_unmapped_to_ext() on the mbuf chain when the
> NIC does not have IFCAP_MEXTPG makes doing
> this an undesirable alternative to generating a longer
> mbuf chain of mbuf clusters?
>
> For my hardware, things just run at wire speed (1Gbps),
> so I do not see any difference between the two cases.
> I do see a 15% improvement for localhost mounts, but
> those hardly matter.
>
> I tester did determine that performance was improved for
> a Mellanox NIC that has IFCAP_MEXTPG. (5-15% depending
> on setup)
>
> I can enable this two ways:
> 1 - A sysctl that is enabled/disabled by default (which means most
>      cases will call mb_unmapped_to_ext() if enabled).
> or
> 2 - Try and check to see if the outbound NIC has IFCAP_MEXTPG.
>     (Note that this does not have to be 100% correct, since the NFS
>      reply works either way.  The reviewer was concerned about routing
>      changes, etc, affecting the result.)
>
> I implemented #2 using the suggested approach, but the
> reviewer (who suggested the approach) decided that doing so
> was not recommended. (D55203 on phabricator.)
>
> So, what do you think is the preferred alternative?
I may have partially answered my own question.
I did a crude measurement of cpu overheads and found that,
for a simple amd64 system with a 1Gbps Intel NIC, that the
overheads appear to be about 10% better (aka lower) when
M_EXTPG mbufs are used.

So, unless others think there are cases where using M_EXTPG
mbufs for read replies is undesirable, I think enabling them by
default regardless of the NIC, might be ok.

rick

>
> rick