On Thu, Jan 06, 2022 at 11:50:54AM +0100, Morten Brørup wrote: > > From: Olivier Matz [mailto:olivier.m...@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 >
