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 B0C5843676; Tue, 5 Dec 2023 11:10:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9D567402C8; Tue, 5 Dec 2023 11:10:26 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 124DC40275 for ; Tue, 5 Dec 2023 11:10:25 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id E7057206C2; Tue, 5 Dec 2023 11:10:24 +0100 (CET) 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 init questions X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 5 Dec 2023 11:10:21 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F08F@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mbuf init questions Thread-Index: AdonYUsLcWE1JT+PTFuFrKwfzJLjuwAAHcoA References: <98CBD80474FA8B44BF855DF32C47DC35E9F08D@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" 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: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Tuesday, 5 December 2023 10.56 >=20 > On Tue, Dec 05, 2023 at 10:07:56AM +0100, Morten Br=F8rup wrote: > > Why is m->nb_segs initialized in rte_pktmbuf_prefree_seg()? > > > > It's part of the m->rearm_data, and will be initialized on RX > descriptor rearm anyway. > > > Presumably this is to have a sane default for apps that allocate > buffers > directly using mempool_get functions. Ahh, yes... the great bypassing of the mbuf APIs! >=20 > Overall, we probably need to document clearly for mbufs allocated = using > mempool apis rather than mbuf_alloc what fields are valid and what = need > to > be initialized. Good point. Since it has become customary - and generally accepted = practice - to bypass the mbuf APIs and use the mempool APIs directly, we = should document how to use the mempool APIs in an mbuf API context. Spaghetti code, but everyone loves the performance benefits by doing it. = Including myself. ;-)