From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id 12262C642 for ; Thu, 30 Jul 2015 15:48:42 +0200 (CEST) Received: by wibud3 with SMTP id ud3so69281652wib.0 for ; Thu, 30 Jul 2015 06:48:42 -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=iVrKPUJm+2SR1DFFJIngNi2bKjq7hewSOWxgdOo6QUQ=; b=HcbhRkJ5Hhd1R5ZaKyK16E9AF3c2QRgRACIk4Jnuuzk9fn1PUqnliEe6RBdoPDx2Q5 5dWyJdUFB8wa9Lj0fD6ySraya+cqO6mUsQTxKoNv92xsaCRNtxg+mexh+xdIEsqWj/ui 9cmTA+QY+zjg/NxAyFyG4t6UecxTn4rPVkIKskocwop98pz+GgsHRw55g2NeLtgJe9Te AylqOMdh5IaPj3O5f77ZymeNAUo/9RjdGPVRq5N9Sxs/7dIE70hVsFGn7Y0Hzxmlh08B b301LxaeAqyYcFQ9Rv6U2CdNSzMx5c3Jp+5gdRYoXRD7OSdeMYoAkI2htQg3VtKo9muq 0A6Q== X-Gm-Message-State: ALoCoQnXcjGEC04z4pIwQLCB+8D/V+Hz8P/f3yo2nADdBiGri9IRjB2JxoABl5Qoqrd0THUqNBQ8 X-Received: by 10.194.121.34 with SMTP id lh2mr88369524wjb.101.1438264121936; Thu, 30 Jul 2015 06:48:41 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.151.210]) by smtp.gmail.com with ESMTPSA id hd6sm29992188wib.19.2015.07.30.06.48.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 06:48:41 -0700 (PDT) From: Thomas Monjalon To: Olivier MATZ Date: Thu, 30 Jul 2015 15:47:26 +0200 Message-ID: <1682615.eOc1hvvtSx@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <55BA08EE.8090902@6wind.com> References: <55B8EC16.60404@allegro-packets.com> <2601191342CEEE43887BDE71AB97725836A6A0CE@irsmsx105.ger.corp.intel.com> <55BA08EE.8090902@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Issue with non-scattered rx in ixgbe and i40e when mbuf private area size is odd 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 13:48:42 -0000 2015-07-30 13:22, Olivier MATZ: > On 07/30/2015 11:43 AM, Ananyev, Konstantin wrote: > > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > >> On 07/30/2015 11:00 AM, Ananyev, Konstantin wrote: > >>> From: Olivier MATZ [mailto:olivier.matz@6wind.com] > >>>> On 07/29/2015 10:24 PM, Zhang, Helin wrote: > >>>>> The similar situation in i40e, as explained by Konstantin. > >>>>> As header split hasn't been supported by DPDK till now. It would be better to put the header address in RX descriptor to 0. > >>>>> But in the future, during header split enabling. We may need to pay extra attention to that. As at least x710 datasheet said > >>>> specifically as below. > >>>>> "The header address should be set by the software to an even number (word aligned address)". We may need to find a way to > >>>> ensure that during mempool/mbuf allocation. > >>>> > >>>> Indeed it would be good to force the priv_size to be aligned. > >>>> > >>>> The priv_size could be aligned automatically in > >>>> rte_pktmbuf_pool_create(). The only possible problem I could see > >>>> is that it would break applications that access to the data buffer > >>>> by doing (sizeof(mbuf) + sizeof(priv)), which is probably not the > >>>> best thing to do (I didn't find any applications like this in dpdk). > >>> > >>> > >>> Might be just make rte_pktmbuf_pool_create() fail if input priv_size % MIN_ALIGN != 0? > >> > >> Hmm maybe it would break more applications: an odd priv_size is > >> probably rare, but a priv_size that is not aligned to 8 bytes is > >> maybe more common. > > > > My thought was that rte_mempool_create() was just introduced in 2.1, > > so if we add extra requirement for the input parameter now - > > there would be no ABI breakage, and not many people started to use it already. > > For me just seems a bit easier and more straightforward then silent alignment - > > user would not have wrong assumptions here. > > Though if you think that a silent alignment would be more convenient > > for most users - I wouldn't insist. > > > Yes, I agree on the principle, but it depends whether this fix > is integrated for 2.1 or not. > I think it may already be a bit late for that, especially as it > is not a very critical bug. > > Thomas, what do you think? It is a fix. Adding a doc comment, an assert and an alignment constraint or a new automatic alignment in the not yet released function shouldn't hurt. A patch would be welcome for 2.1. Thanks