From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 31D465934 for ; Mon, 27 Jun 2016 16:30:40 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id r201so118072797wme.1 for ; Mon, 27 Jun 2016 07:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=rIfxAsEVntM3HHA9luYU08KR5i9ZZdsuqwAG0/ahcp4=; b=m/fjIX4VuSKxHAXKn8tkRauR8ITta3z85QYE9BQpgm/F8Rx/iXQtleodAcFVf4KCGv oJtSDycAHQoJyWdCVJtDgq/B+iTII72gQkeBmQgFolO+G+VcWYcBatfruTK1SXykopK1 qF0qFx+V7+rzENDQx1o2Efzpod6qM2IrQYGYNdOZV2WznveNf6xj8yjrRxN97Ok3zlD+ BmRuzl0jlLc2XCazIGwRxrc3dpfB1WNxP4vOmmJjg3mdPt30fE73DqJhwBARp3xly8c6 YuVsf0ugKSApZHAQDzucPXRz/UUiRQOnqiHQ+KbB2H2/D2jRvqI9H4ZiaBl1jwbXJUvU bi8g== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=rIfxAsEVntM3HHA9luYU08KR5i9ZZdsuqwAG0/ahcp4=; b=hk9nj48T0FdKzy3pPMwZ2+f2FsjSB1bA6N4i6FubmXPFRYPWWdCchcTltFvbZ54MPM eytJ3YJtbivD5srhIm1Ynx78JF1xSRLGN7LGwunZ21PP84MQRStgkw9PlyHqF9OFKXNk CX1bIn9yymxkONbSEYlk6Pz37v5FnknF7EeqICpBxST9CYFPXMits9FD6cinRhNuRcd6 MPF87difksQz4mEsYOoPfQwsoZFe02WdgUKV320ztbupEALKR4BQeT4qgI3J4JW3ke+0 9v0j524iEwRrnPA2iNFVXPYrOuZ4eFEU50nmEwBEKy48Kmsw+QxDRoLR1nj6l1Bw8dgc 1cnw== X-Gm-Message-State: ALyK8tLUAA5gQU8/72XgJE+uWr1rhR9WmZBVg7aZAoOKwkHIu8T+u7w7/AU+MrqKwrTex6r4 X-Received: by 10.28.129.197 with SMTP id c188mr11611051wmd.46.1467037839854; Mon, 27 Jun 2016 07:30:39 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id z5sm5512674wme.5.2016.06.27.07.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2016 07:30:39 -0700 (PDT) From: Thomas Monjalon To: "Wiles, Keith" Cc: dev@dpdk.org, Olivier Matz , "Ananyev, Konstantin" Date: Mon, 27 Jun 2016 16:30:38 +0200 Message-ID: <8530000.4NpoyoCY28@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <73B00DD6-F266-4A76-8C4E-F875C16D6977@intel.com> References: <1466868582-66201-1-git-send-email-keith.wiles@intel.com> <1706546.bAg9N1Gdxd@xps13> <73B00DD6-F266-4A76-8C4E-F875C16D6977@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Subject: Re: [dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly 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: Mon, 27 Jun 2016 14:30:40 -0000 2016-06-27 13:06, Wiles, Keith: >=20 > On 6/27/16, 4:05 AM, "Thomas Monjalon" wr= ote: >=20 > >2016-06-27 10:27, Olivier Matz: > >> On 06/27/2016 10:21 AM, Ananyev, Konstantin wrote: > >> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles= > >> >> Move the next pointer to the first cacheline of the rte_mbuf st= ructure > >> >> and move the offload values to the second cacheline to give bet= ter > >> >> performance to applications using chained mbufs. > >> >> > >> >> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDL= Y default > >> >> is set to No. > >> >=20 > >> > First, it would make ixgbe and i40e vector RX functions to work = incorrectly. > >> > Second, I don't think we can afford to allow people swap mbuf fi= elds in the way they like. > >> > Otherwise we'll end-up with totally unmaintainable code pretty s= oon. > >> > So NACK. =20 > >>=20 > >> +1 > > > >To be more precise, the arrangement of fields in rte_mbuf is open > >to debate and changes. > >There is a recent discussion here: > >=09http://dpdk.org/ml/archives/dev/2016-May/039483.html > > > >I think we must try to improve few things in mbuf during the 16.11 c= ycle. > >But it must not be allowed to have a build option to adapt this stru= cture > >or any other API. There is only one DPDK API for a given version. >=20 > I just received a private email thread on this one and it appears it = is not a big of a problem as was stated before. =E2=98=B9 So yes we can= reject this one. >=20 > Someone rejected these in patchwork already, which I expected I would= be the one to reject the patches. Is this not the case? I understand i= f the patch just hangs round, but I would have expected after the list = rejected the patch I would be the one to reject the patches. I try to k= eep up with my patches and rejecting a patch before I have a chance to = do so seems a bit harsh to me. Yes it's me, sorry I've been quick when I've seen the first 2 comments.=