From: Olivier Matz <olivier.matz@6wind.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org
Subject: Re: mbuf headroom question
Date: Thu, 6 Jan 2022 13:41:27 +0100 [thread overview]
Message-ID: <Ydbjd0S2adsN5z8e@platinum> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86DE2@smartserver.smartshare.dk>
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
>
next prev parent reply other threads:[~2022-01-06 12:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-06 9:29 Morten Brørup
2022-01-06 9:48 ` Olivier Matz
2022-01-06 10:50 ` Morten Brørup
2022-01-06 12:41 ` Olivier Matz [this message]
2022-01-06 12:49 ` Morten Brørup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ydbjd0S2adsN5z8e@platinum \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).