From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id E5999C65E for ; Thu, 30 Jul 2015 18:07:07 +0200 (CEST) Received: by wibxm9 with SMTP id xm9so75219935wib.1 for ; Thu, 30 Jul 2015 09:07:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SW3L6sqriJXYHJ8r5fbHozETmT2TIr8GSuEIL9FdBlk=; b=bA64rOKE3LrS1ZjfPj+WVBqC82EyDoGYlOV1fVhcMbyCwmUPm8hGbIMID2y5C8tKTN kFKDsGaUriKdlgGd98Aoa0t4mDOUWYBFjeluRmUXzLWg62tDFD/zH5KV4n+cJdvpuFVg npi7q6wGmODSe4dM9BExNTQ42YiUwZQ05wpsHwcAMoxttt+jP1P+jZJ2EB9hQVCPnplL TYreQvEGJgu3nhd3iX/4GezErakidgkeec/6X5xiL68Ak6MxYeLE43u/i59Nvh4EQ5rS +0IU5FgOuc+heR7D5miNFRT1i9FoAFq6D9oFQo4ik0eIGr9grmvuR9yBHLzsRtDoE84A jr8g== X-Gm-Message-State: ALoCoQl8xyF36BRu8s4YBNBq1OkK9eNvVFOyRqbakzJKhcKgg0nlyyJM1tnphq8peDpkVLNA0D7x X-Received: by 10.180.21.244 with SMTP id y20mr7802187wie.65.1438272427510; Thu, 30 Jul 2015 09:07:07 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.151.210]) by smtp.gmail.com with ESMTPSA id n6sm3759816wix.1.2015.07.30.09.07.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 09:07:06 -0700 (PDT) Message-ID: <55BA4BA2.3010007@6wind.com> Date: Thu, 30 Jul 2015 18:06:58 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" References: <1682615.eOc1hvvtSx@xps13> <1438264561-18359-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB97725836A6B237@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836A6B237@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] mbuf: enforce alignment of mbuf private area X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:07:08 -0000 On 07/30/2015 04:13 PM, Ananyev, Konstantin wrote: > > Hi Olivier, > > If fails to compile for me: > > /local/kananye1/dpdk.org-mbprv1/lib/librte_mbuf/rte_mbuf.c: In function ârte_pktmbuf_pool_createâ: > /local/kananye1/dpdk.org-mbprv1/lib/librte_mbuf/rte_mbuf.c:161:3: error: ârte_errnoâ undeclared (first use in this function) > rte_errno = EINVAL; > ^ > /local/kananye1/dpdk.org-mbprv1/lib/librte_mbuf/rte_mbuf.c:161:3: note: each undeclared identifier is reported only once for each function it appears in > > I had to add: Sorry I had the same error but I forgot to squash the fix... :/ I'm sending a v2 > > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c > index a1ddbb3..04344c0 100644 > --- a/lib/librte_mbuf/rte_mbuf.c > +++ b/lib/librte_mbuf/rte_mbuf.c > @@ -58,6 +58,7 @@ > #include > #include > #include > +#include > > /* > * ctrlmbuf constructor, given as a callback function to > > Apart from that - looks good to me. > Konstantin > >> -----Original Message----- >> From: Olivier Matz [mailto:olivier.matz@6wind.com] >> Sent: Thursday, July 30, 2015 2:56 PM >> To: dev@dpdk.org >> Cc: Ananyev, Konstantin; olivier.matz@6wind.com; Zhang, Helin; martin.weiser@allegro-packets.com; thomas.monjalon@6wind.com >> Subject: [PATCH] mbuf: enforce alignment of mbuf private area >> >> It looks better to have a data buffer address that is aligned to >> 8 bytes. This is the case when there is no mbuf private area, but >> if there is one, the alignment depends on the size of this area >> that is located between the mbuf structure and the data buffer. >> >> Indeed, some drivers expects to have the buffer address aligned >> to an even address, and moreover an unaligned buffer may impact >> the performance when accessing to network headers. >> >> Add a check in rte_pktmbuf_pool_create() to verify the alignment >> constraint before creating the mempool. For applications that use >> the alternative way (direct call to rte_mempool_create), also >> add an assertion in rte_pktmbuf_init(). >> >> By the way, also add the MBUF log type. >> >> Signed-off-by: Olivier Matz >> --- >> lib/librte_eal/common/include/rte_log.h | 1 + >> lib/librte_mbuf/rte_mbuf.c | 8 +++++++- >> lib/librte_mbuf/rte_mbuf.h | 7 +++++-- >> 3 files changed, 13 insertions(+), 3 deletions(-) >> >> diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h >> index 24a55cc..ede0dca 100644 >> --- a/lib/librte_eal/common/include/rte_log.h >> +++ b/lib/librte_eal/common/include/rte_log.h >> @@ -77,6 +77,7 @@ extern struct rte_logs rte_logs; >> #define RTE_LOGTYPE_PORT 0x00002000 /**< Log related to port. */ >> #define RTE_LOGTYPE_TABLE 0x00004000 /**< Log related to table. */ >> #define RTE_LOGTYPE_PIPELINE 0x00008000 /**< Log related to pipeline. */ >> +#define RTE_LOGTYPE_MBUF 0x00010000 /**< Log related to mbuf. */ >> >> /* these log types can be used in an application */ >> #define RTE_LOGTYPE_USER1 0x01000000 /**< User-defined log type 1. */ >> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c >> index 4320dd4..a1ddbb3 100644 >> --- a/lib/librte_mbuf/rte_mbuf.c >> +++ b/lib/librte_mbuf/rte_mbuf.c >> @@ -125,6 +125,7 @@ rte_pktmbuf_init(struct rte_mempool *mp, >> mbuf_size = sizeof(struct rte_mbuf) + priv_size; >> buf_len = rte_pktmbuf_data_room_size(mp); >> >> + RTE_MBUF_ASSERT((priv_size & (RTE_MBUF_PRIV_ALIGN - 1)) == 0); >> RTE_MBUF_ASSERT(mp->elt_size >= mbuf_size); >> RTE_MBUF_ASSERT(buf_len <= UINT16_MAX); >> >> @@ -154,7 +155,12 @@ rte_pktmbuf_pool_create(const char *name, unsigned n, >> struct rte_pktmbuf_pool_private mbp_priv; >> unsigned elt_size; >> >> - >> + if ((priv_size & (RTE_MBUF_PRIV_ALIGN - 1)) != 0) { >> + RTE_LOG(ERR, MBUF, "mbuf priv_size=%u is not aligned\n", >> + priv_size); >> + rte_errno = EINVAL; >> + return NULL; >> + } >> elt_size = sizeof(struct rte_mbuf) + (unsigned)priv_size + >> (unsigned)data_room_size; >> mbp_priv.mbuf_data_room_size = data_room_size; >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h >> index 010b32d..c3b8c98 100644 >> --- a/lib/librte_mbuf/rte_mbuf.h >> +++ b/lib/librte_mbuf/rte_mbuf.h >> @@ -698,6 +698,9 @@ extern "C" { >> RTE_PTYPE_INNER_L4_MASK)) >> #endif /* RTE_NEXT_ABI */ >> >> +/** Alignment constraint of mbuf private area. */ >> +#define RTE_MBUF_PRIV_ALIGN 8 >> + >> /** >> * Get the name of a RX offload flag >> * >> @@ -1238,7 +1241,7 @@ void rte_pktmbuf_pool_init(struct rte_mempool *mp, void *opaque_arg); >> * details. >> * @param priv_size >> * Size of application private are between the rte_mbuf structure >> - * and the data buffer. >> + * and the data buffer. This value must be aligned to RTE_MBUF_PRIV_ALIGN. >> * @param data_room_size >> * Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM. >> * @param socket_id >> @@ -1250,7 +1253,7 @@ void rte_pktmbuf_pool_init(struct rte_mempool *mp, void *opaque_arg); >> * with rte_errno set appropriately. Possible rte_errno values include: >> * - E_RTE_NO_CONFIG - function could not get pointer to rte_config structure >> * - E_RTE_SECONDARY - function was called from a secondary process instance >> - * - EINVAL - cache size provided is too large >> + * - EINVAL - cache size provided is too large, or priv_size is not aligned. >> * - ENOSPC - the maximum number of memzones has already been allocated >> * - EEXIST - a memzone with the same name already exists >> * - ENOMEM - no appropriate memory area found in which to create memzone >> -- >> 2.1.4 >