From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 28709A034E; Thu, 6 Jan 2022 13:49:29 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DBA0741151; Thu, 6 Jan 2022 13:49:28 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id B4F1141150 for ; Thu, 6 Jan 2022 13:49:27 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: mbuf headroom question Date: Thu, 6 Jan 2022 13:49:23 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86DE4@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mbuf headroom question Thread-Index: AdgC+rzyNz84E4GsShWFXdC015UGDgAAFs8g References: <98CBD80474FA8B44BF855DF32C47DC35D86DE0@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D86DE2@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Olivier Matz" Cc: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Thursday, 6 January 2022 13.41 >=20 > On Thu, Jan 06, 2022 at 11:50:54AM +0100, Morten Br=F8rup 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=F8rup 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. >=20 > Well, not really ignore data_off. The application can use > rte_pktmbuf_prepend(). >=20 > > > 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. >=20 > 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. >=20 > > > > 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 > >