From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id F0E37C430 for ; Mon, 3 Aug 2015 00:36:46 +0200 (CEST) Received: by wicmv11 with SMTP id mv11so114243641wic.0 for ; Sun, 02 Aug 2015 15:36:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=YtlU6fmV7LIDjzq+egzgjO+0oL6TmMYWj2vcOrf74J4=; b=AHqfOxcDz5K+Wp521GK3JUVlPhmFHGRQvCB1VqyvwA4MMgaPxoll3kNutkPz02KxzH iGZGgN5Km93mXC+RLMpzU23fF2JATMXGnaLZ+A4KmrUo3+3IucR229G2bCzxT7lW64a6 Zl+FUQ2dwX0Iiq8cuv4gGg7Br0H9BN4DDsZuEc5L6YtH3r4pGQ/WwL5N+VVLrcrLj6Ek ReOCypKMGAKqec/sWZQB6hJfthSsDWM9vncN1TxG5072bseMQg28F9id6HizLxZZnBS5 wSwTGQrBPpqIx/PhImoWikBB5vDrwNEtZVmLub79n5bCZAZacmS4/fS+wfTY/mR+U9h8 ltVg== X-Gm-Message-State: ALoCoQlK8TRU41N8hQlbq0dJb6ysAtuPigRGrUN0somDk+oBlL6qHJOlZLV8oM1BZzyr7Amh3EW7 X-Received: by 10.194.89.98 with SMTP id bn2mr30858246wjb.153.1438555006859; Sun, 02 Aug 2015 15:36:46 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id bq7sm19628683wjc.31.2015.08.02.15.36.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Aug 2015 15:36:46 -0700 (PDT) From: Thomas Monjalon To: Olivier Matz Date: Mon, 03 Aug 2015 00:35:32 +0200 Message-ID: <4068420.gylT6sbKzz@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB97725836A6B5A2@irsmsx105.ger.corp.intel.com> References: <1438264561-18359-1-git-send-email-olivier.matz@6wind.com> <1438273337-13211-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB97725836A6B5A2@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] 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: Sun, 02 Aug 2015 22:36:47 -0000 > > 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 > > Acked-by: Konstantin Ananyev Applied, thanks