mbuf headroom question

mbuf headroom question

[Morten Brørup]

Hi Olivier,

The data_room_size parameter description for the mbuf pool creation functions says:
"Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM."

Furthermore, both rte_mbuf_data_iova_default() and rte_mbuf_data_addr_default() simply add RTE_PKTMBUF_HEADROOM to the return value.

Based on the above, I would think that it is impossible for m->buf_len to be smaller than RTE_PKTMBUF_HEADROOM.

So why does rte_pktmbuf_reset_headroom() use RTE_MIN(m->buf_len, RTE_PKTMBUF_HEADROOM), instead of just RTE_PKTMBUF_HEADROOM? What am I missing here?


Med venlig hilsen / Kind regards,
-Morten Brørup

Re: mbuf headroom question

[Olivier Matz]

Hi Morten,

On Thu, Jan 06, 2022 at 10:29:11AM +0100, Morten Brørup wrote:
> Hi Olivier,
> 
> The data_room_size parameter description for the mbuf pool creation functions says:
> "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM."
> 
> Furthermore, both rte_mbuf_data_iova_default() and rte_mbuf_data_addr_default() simply add RTE_PKTMBUF_HEADROOM to the return value.
> 
> Based on the above, I would think that it is impossible for m->buf_len to be smaller than RTE_PKTMBUF_HEADROOM.
> 
> So why does rte_pktmbuf_reset_headroom() use RTE_MIN(m->buf_len, RTE_PKTMBUF_HEADROOM), instead of just RTE_PKTMBUF_HEADROOM? What am I missing here?

It is legal to create a packet pool that has no data buffer: this pool
can be used to allocate packets clones that will be attached to mbufs
containing data. There is an example in test_mbuf.c.

It is also technically possible to create a packet pool with small
mbufs (whose buffer length is less than RTE_PKTMBUF_HEADROOM). These
mbufs cannot be used by drivers which use rte_mbuf_data_iova_default(),
but they could be used internally.

To create valid mbufs in these 2 cases, this is why RTE_MIN(m->buf_len,
RTE_PKTMBUF_HEADROOM) is used ; "valid" means that headroom is not larger
than buffer length.


Olivier

RE: mbuf headroom question

[Morten Brørup]

> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, 6 January 2022 10.49

Thank you for the thorough explanation, Olivier.

Somewhat exotic scenarios, but they do make sense!

As you might have guessed, I was wondering if rte_pktmbuf_reset_headroom() could be optimized by simply using RTE_PKTMBUF_HEADROOM. I still think that it might, but I realize that it would have wider reaching consequences...

> 
> Hi Morten,
> 
> On Thu, Jan 06, 2022 at 10:29:11AM +0100, Morten Brørup wrote:
> > Hi Olivier,
> >
> > The data_room_size parameter description for the mbuf pool creation
> functions says:
> > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM."
> >
> > Furthermore, both rte_mbuf_data_iova_default() and
> rte_mbuf_data_addr_default() simply add RTE_PKTMBUF_HEADROOM to the
> return value.
> >
> > Based on the above, I would think that it is impossible for m-
> >buf_len to be smaller than RTE_PKTMBUF_HEADROOM.
> >
> > So why does rte_pktmbuf_reset_headroom() use RTE_MIN(m->buf_len,
> RTE_PKTMBUF_HEADROOM), instead of just RTE_PKTMBUF_HEADROOM? What am I
> missing here?
> 
> It is legal to create a packet pool that has no data buffer: this pool
> can be used to allocate packets clones that will be attached to mbufs
> containing data. There is an example in test_mbuf.c.

In this case, m->data_off is unused, and could be RTE_PKTMBUF_HEADROOM without causing problems.

> 
> It is also technically possible to create a packet pool with small
> mbufs (whose buffer length is less than RTE_PKTMBUF_HEADROOM). These
> mbufs cannot be used by drivers which use rte_mbuf_data_iova_default(),
> but they could be used internally.

In this case, all of the mbuf's data buffer would be headroom, so the internal use be application/drivers would need to ignore m->data_ off anyway, and could be RTE_PKTMBUF_HEADROOM without causing problems.

> 
> To create valid mbufs in these 2 cases, this is why RTE_MIN(m->buf_len,
> RTE_PKTMBUF_HEADROOM) is used ; "valid" means that headroom is not
> larger
> than buffer length.

Validity is important! So if we optimized rte_pktmbuf_reset_headroom(), all the related validation functions would need to be updated accordingly. And the description of the data_off field in the mbuf.

It is probably not worth the effort pursuing this idea any further. :-)

> 
> 
> Olivier

Re: mbuf headroom question

[Olivier Matz]

On Thu, Jan 06, 2022 at 11:50:54AM +0100, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, 6 January 2022 10.49
> 
> Thank you for the thorough explanation, Olivier.
> 
> Somewhat exotic scenarios, but they do make sense!
> 
> As you might have guessed, I was wondering if rte_pktmbuf_reset_headroom() could be optimized by simply using RTE_PKTMBUF_HEADROOM. I still think that it might, but I realize that it would have wider reaching consequences...
> 
> > 
> > Hi Morten,
> > 
> > On Thu, Jan 06, 2022 at 10:29:11AM +0100, Morten Brørup wrote:
> > > Hi Olivier,
> > >
> > > The data_room_size parameter description for the mbuf pool creation
> > functions says:
> > > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM."
> > >
> > > Furthermore, both rte_mbuf_data_iova_default() and
> > rte_mbuf_data_addr_default() simply add RTE_PKTMBUF_HEADROOM to the
> > return value.
> > >
> > > Based on the above, I would think that it is impossible for m-
> > >buf_len to be smaller than RTE_PKTMBUF_HEADROOM.
> > >
> > > So why does rte_pktmbuf_reset_headroom() use RTE_MIN(m->buf_len,
> > RTE_PKTMBUF_HEADROOM), instead of just RTE_PKTMBUF_HEADROOM? What am I
> > missing here?
> > 
> > It is legal to create a packet pool that has no data buffer: this pool
> > can be used to allocate packets clones that will be attached to mbufs
> > containing data. There is an example in test_mbuf.c.
> 
> In this case, m->data_off is unused, and could be RTE_PKTMBUF_HEADROOM without causing problems.
> 
> > 
> > It is also technically possible to create a packet pool with small
> > mbufs (whose buffer length is less than RTE_PKTMBUF_HEADROOM). These
> > mbufs cannot be used by drivers which use rte_mbuf_data_iova_default(),
> > but they could be used internally.
> 
> In this case, all of the mbuf's data buffer would be headroom, so the internal use be application/drivers would need to ignore m->data_ off anyway, and could be RTE_PKTMBUF_HEADROOM without causing problems.

Well, not really ignore data_off. The application can use
rte_pktmbuf_prepend().

> > To create valid mbufs in these 2 cases, this is why RTE_MIN(m->buf_len,
> > RTE_PKTMBUF_HEADROOM) is used ; "valid" means that headroom is not
> > larger
> > than buffer length.
> 
> Validity is important! So if we optimized rte_pktmbuf_reset_headroom(), all the related validation functions would need to be updated accordingly. And the description of the data_off field in the mbuf.

Yes. Currently, it is possible to use rte_pktmbuf_prepend(),
rte_pktmbuf_append(), and others on these mbufs. They will return
an error if data cannot be added.

> 
> It is probably not worth the effort pursuing this idea any further. :-)
> 
> > 
> > 
> > Olivier
> 

RE: mbuf headroom question

[Morten Brørup]

> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, 6 January 2022 13.41
> 
> On Thu, Jan 06, 2022 at 11:50:54AM +0100, Morten Brørup wrote:
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Thursday, 6 January 2022 10.49
> >
> > Thank you for the thorough explanation, Olivier.
> >
> > Somewhat exotic scenarios, but they do make sense!
> >
> > As you might have guessed, I was wondering if
> rte_pktmbuf_reset_headroom() could be optimized by simply using
> RTE_PKTMBUF_HEADROOM. I still think that it might, but I realize that
> it would have wider reaching consequences...
> >
> > >
> > > Hi Morten,
> > >
> > > On Thu, Jan 06, 2022 at 10:29:11AM +0100, Morten Brørup wrote:
> > > > Hi Olivier,
> > > >
> > > > The data_room_size parameter description for the mbuf pool
> creation
> > > functions says:
> > > > "Size of data buffer in each mbuf, including
> RTE_PKTMBUF_HEADROOM."
> > > >
> > > > Furthermore, both rte_mbuf_data_iova_default() and
> > > rte_mbuf_data_addr_default() simply add RTE_PKTMBUF_HEADROOM to the
> > > return value.
> > > >
> > > > Based on the above, I would think that it is impossible for m-
> > > >buf_len to be smaller than RTE_PKTMBUF_HEADROOM.
> > > >
> > > > So why does rte_pktmbuf_reset_headroom() use RTE_MIN(m->buf_len,
> > > RTE_PKTMBUF_HEADROOM), instead of just RTE_PKTMBUF_HEADROOM? What
> am I
> > > missing here?
> > >
> > > It is legal to create a packet pool that has no data buffer: this
> pool
> > > can be used to allocate packets clones that will be attached to
> mbufs
> > > containing data. There is an example in test_mbuf.c.
> >
> > In this case, m->data_off is unused, and could be
> RTE_PKTMBUF_HEADROOM without causing problems.
> >
> > >
> > > It is also technically possible to create a packet pool with small
> > > mbufs (whose buffer length is less than RTE_PKTMBUF_HEADROOM).
> These
> > > mbufs cannot be used by drivers which use
> rte_mbuf_data_iova_default(),
> > > but they could be used internally.
> >
> > In this case, all of the mbuf's data buffer would be headroom, so the
> internal use be application/drivers would need to ignore m->data_ off
> anyway, and could be RTE_PKTMBUF_HEADROOM without causing problems.
> 
> Well, not really ignore data_off. The application can use
> rte_pktmbuf_prepend().
> 
> > > To create valid mbufs in these 2 cases, this is why RTE_MIN(m-
> >buf_len,
> > > RTE_PKTMBUF_HEADROOM) is used ; "valid" means that headroom is not
> > > larger
> > > than buffer length.
> >
> > Validity is important! So if we optimized
> rte_pktmbuf_reset_headroom(), all the related validation functions
> would need to be updated accordingly. And the description of the
> data_off field in the mbuf.
> 
> Yes. Currently, it is possible to use rte_pktmbuf_prepend(),
> rte_pktmbuf_append(), and others on these mbufs. They will return
> an error if data cannot be added.
> 
> >
> > It is probably not worth the effort pursuing this idea any further.
> :-)

Considering the last feedback from Olivier, it is *certainly* not worth pursuing this idea any further. :-)

> >
> > >
> > >
> > > Olivier
> >