From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly Date: Mon, 27 Jun 2016 16:30:38 +0200 Message-ID: <8530000.4NpoyoCY28@xps13> 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-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Olivier Matz , "Ananyev, Konstantin" To: "Wiles, Keith" 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) In-Reply-To: <73B00DD6-F266-4A76-8C4E-F875C16D6977@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.=