From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH v2 13/41] eal: replace memseg with memseg lists Date: Sat, 24 Mar 2018 11:08:01 +0000 Message-ID: References: <495e60f4e02af8a344c0f817a60d1ee9b9322df4.1520428025.git.anatoly.burakov@intel.com> <15b7a198-2963-30e1-9d31-abbe01dd62d1@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Monjalon , Yuanhan Liu , Maxime Coquelin , Tiwei Bie , keith.wiles@intel.com, jianfeng.tan@intel.com, andras.kovacs@ericsson.com, laszlo.vadkeri@ericsson.com, benjamin.walker@intel.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, kuralamudhan.ramakrishnan@intel.com, louise.m.daly@intel.com, nelio.laranjeiro@6wind.com, yskoh@mellanox.com, pepperjo@japf.ch, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, olivier.matz@6wind.com To: santosh , dev@dpdk.org Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A059C5F19 for ; Sat, 24 Mar 2018 12:08:10 +0100 (CET) In-Reply-To: <15b7a198-2963-30e1-9d31-abbe01dd62d1@caviumnetworks.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 24-Mar-18 6:01 AM, santosh wrote: > Hi Anatoly, > > Thanks for good work!. > Few observations: > # Noticed performance regression for thunderx platform for l3fwd application, > drops by 3%. git bisect shows this changeset is offending commit. > I'm still investigating reason for perf-dip.. > Would like to know - have you noticed any regression on x86 platform? I haven't noticed any regressions on x86. Would it by any chance be due to the fact that memory segments are now non-contiguous or are allocated from smaller page sizes first? I am in the process of preparing a v3, which moves some things around and is better at git bisect (and fixes all compile issues i am or was made aware of). Does performance regression also happen in legacy mode? Thanks for testing! > Perhaps you may club all below comits into one single patch, > as changes are identical... that way you'd reduce patch count by few less. > 9a1e2a7bd9f6248c680ad3e444b6f173eb92d457 net/vmxnet3: use contiguous allocation for DMA memory > 46388b194cd559b5cf7079e01b04bf67a99b64d7 net/virtio: use contiguous allocation for DMA memory > a3d2eb10bd998ba3ae3a3d39adeaff38d2e53a9d net/qede: use contiguous allocation for DMA memory > 6f16b23ef1f472db475edf05159dea5ae741dbf8 net/i40e: use contiguous allocation for DMA memory > f9f7576eed35cb6aa50793810cdda43bcc0f4642 net/enic: use contiguous allocation for DMA memory > 2af6c33009b8008da7028a351efed2932b1a13d0 net/ena: use contiguous allocation for DMA memory > 18003e22bd7087e5e2e03543cb662d554f7bec52 net/cxgbe: use contiguous allocation for DMA memory > 59f79182502dcb3634dfa3e7b918195829777460 net/bnx2x: use contiguous allocation for DMA memory > f481a321e41da82ddfa00f5ddbcb42fc29e6ae76 net/avf: use contiguous allocation for DMA memory > 5253e9b757c1855a296656d939f5c28e651fea69 crypto/qat: use contiguous allocation for DMA memory > 297ab037b4c0d9d725aa6cfdd2c33f7cd9396899 ethdev: use contiguous allocation for DMA memory I would like to keep these as separate patches. It makes it easier to track which changes were accepted by maintainers of respective drivers, and which weren't. -- Thanks, Anatoly