RFC: Drop support for undersize packet mbufs

[Morten Brørup]

> From: fengchengwen [mailto:fengchengwen at huawei.com]
> Sent: Monday, 18 August 2025 12.58
> 
> On 8/18/2025 4:11 PM, Morten Brørup wrote:
> > Why does the mbuf library support packet mbufs with smaller data room size
> than RTE_PKTMBUF_HEADROOM (e.g. [1]), when the Ethdev drivers (e.g. [2]) don't
> support it?
> 
> Maybe the pktmbuf which extbuf, which the data-room-size is zero when create
> pktmbuf.

The descriptions of all the rte_pktmbuf_pool_create() functions - including rte_pktmbuf_pool_create_extbuf() - specify that the data-room-size must be >=RTE_PKTMBUF_HEADROOM:

 * @param data_room_size
 *   Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM.

So it might be related to dynamically attached (non-pinned) extbufs being smaller than RTE_PKTMBUF_HEADROOM. When resetting such a packet mbuf, it will be all headroom and have zero room for data.
How is this useful?
Do any real applications really use such small non-pinned extbufs?

> After detach from extbuf, the data_off should be zero instead of
> RTE_PKTMBUF_HEADROOM.

In this case, the pktmbuf pool must have been created with the mempool library (bypassing the mbuf library), which is perfectly valid and described in the mbuf library as an alternative way of creating mbuf pools.
So, after detaching the extbuf, the packet mbuf has a very small data-room-size (possibly zero).
Is the mbuf going to be used for anything in this state? I.e. does the data_off need to be valid in this state?

> 
> >
> > This goes all the way back to the first public release [3].

I suspect the support for undersize (i.e. smaller than RTE_PKTMBUF_HEADROOM) data-room-size is obsolete, and might have something to do with mbufs originally being used for other purposes than packets (e.g. non-packet messages).

> >
> > It seems crazy exotic, and should be removed for simplicity and a potential
> performance benefit.
> > What am I missing here?
> >
> > Instead, the rte_pktmbuf_pool_create() functions should check that
> data_room_size >= RTE_PKTMBUF_HEADROOM.
> >
> >
> > [1]: https://elixir.bootlin.com/dpdk/v25.07/source/lib/mbuf/rte_mbuf.h#L941
> > static inline void rte_pktmbuf_reset_headroom(struct rte_mbuf *m)
> > {
> > 	m->data_off = (uint16_t)RTE_MIN((uint16_t)RTE_PKTMBUF_HEADROOM,
> > 					(uint16_t)m->buf_len);
> > }
> >
> > [2]:
> https://elixir.bootlin.com/dpdk/v25.07/source/drivers/net/intel/i40e/i40e_rxtx
> .c#L609
> > mb->data_off = RTE_PKTMBUF_HEADROOM;
> >
> > [3]:
> https://git.dpdk.org/dpdk/commit/lib/librte_mbuf?id=af75078fece3615088e561357c
> 1e97603e43a5fe
> > +static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> > +{
> > +	uint32_t buf_ofs;
> > +
> > +	m->pkt.next = NULL;
> > +	m->pkt.pkt_len = 0;
> > +	m->pkt.l2_len = 0;
> > +	m->pkt.l3_len = 0;
> > +	m->pkt.vlan_tci = 0;
> > +	m->pkt.nb_segs = 1;
> > +	m->pkt.in_port = 0xff;
> > +
> > +	m->ol_flags = 0;
> > +	buf_ofs = (RTE_PKTMBUF_HEADROOM <= m->buf_len) ?
> > +			RTE_PKTMBUF_HEADROOM : m->buf_len;
> > +	m->pkt.data = (char*) m->buf_addr + buf_ofs;
> > +
> > +	m->pkt.data_len = 0;
> > +	__rte_mbuf_sanity_check(m, RTE_MBUF_PKT, 1);
> > +}
> >
> >
> >
> > Med venlig hilsen / Kind regards,
> > -Morten Brørup
> >