From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 26EBE14E8 for ; Fri, 1 Dec 2017 15:56:05 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2017 06:56:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,344,1508828400"; d="scan'208";a="182451355" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga005.fm.intel.com with ESMTP; 01 Dec 2017 06:56:04 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.67]) by IRSMSX106.ger.corp.intel.com ([169.254.8.36]) with mapi id 14.03.0319.002; Fri, 1 Dec 2017 14:56:03 +0000 From: "Ananyev, Konstantin" To: "dev@dpdk.org" Thread-Topic: [RFC PATCH 0/3] *** SUBJECT HERE *** Thread-Index: AQHTarNzZ0fhcSJbSUeLh+FPYt9Mr6Muk28A Date: Fri, 1 Dec 2017 14:56:02 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772585FAC37D0@irsmsx105.ger.corp.intel.com> References: <1512139682-11114-1-git-send-email-konstantin.ananyev@intel.com> In-Reply-To: <1512139682-11114-1-git-send-email-konstantin.ananyev@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGFjOWY2NjctODcyNy00MTQxLWJlM2QtYmUwMWYyZmMwOTRiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImREVlBiMHl2OVMzXC9mRDVheStHR0VrWVR2RGZDellmUHRwZnIxalozcnlrPSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 0/3] *** SUBJECT HERE *** X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:56:06 -0000 Oops sorry, resending with proper subject. > -----Original Message----- > From: Ananyev, Konstantin > Sent: Friday, December 1, 2017 2:48 PM > To: dev@dpdk.org; dev@dpdk.org > Cc: Ananyev, Konstantin > Subject: [RFC PATCH 0/3] *** SUBJECT HERE *** >=20 > The series introduces 2 main changes: >=20 > 1.Introduce a separate data structure (rte_eth_queue_local) > to store local to given process (i.e. no-shareable) information > for each configured rx/tx queue. > Memory for that structure is allocated/freed dynamically during > rte_eth_dev_configure(). > Reserve a space for queue specific (rx|tx)_pkt_burst(), > tx_pkt_prepare() function pointers inside that structure. > Move rx/tx callback related information inside that structure. > That introduces a change in current behavior: all callbacks for > un-configured queues will be automatically removed. > Also as size of struct rte_eth_dev changes that patch is an ABI breakage, > so deprecation notice for 18.05 is filled. > Further suggestions how to introduce the same functionality > without ABI breakage are welcome. >=20 > 2. Make it safe to remove rx/tx callback at runtime. > Right now it is not possible for the application to figure out > when it is safe to free removed callback handle and > associated with it resources(unless the queue is stopped). > That's probably not a big problem if all callbacks are static > hange through whole application lifetime) > and/or application doesn't allocate any resources for the callback handle= r. > Though if callbacks have to be added/removed dynamically and > callback handler would require more resources to operate properly - > then it might become an issue. > So patch #2 fixes that problem - now as soon as > rte_eth_remove_(rx|tx)_callback() completes successfully, application > can safely free all associated with the removed callback resources. >=20 > Performance impact: > If application doesn't use RX/TX callbacks, then the tests I run didn't > reveal any performance degradation. > Though if application do use RX/TX callbacks - patch #2 does introduce > some slowdown. >=20 > To be more specific here, on BDW (E5-2699 v4) 2.2GHz, 4x10Gb (X520-4) > with http://dpdk.org/dev/patchwork/patch/31864/ patch installed I got: > 1) testpmd ... --latencystats=3D1 - slowdown < 1% > 2) examples//l3fwd ... --parse-ptype - - slowdown < 1% > 3) examples/rxtx_callbacks - slowdown ~8% > All that in terms of packet throughput (Mpps). >=20 > Ability to safely remove callbacks at runtime implies > some sort of synchronization. > Even I tried to make it as light as possible, > probably some slowdown is unavoidable. > Of course instead of introducing these changes at rte_ethdev layer > similar technique could be applied on individual callback basis. > In that case it would be up to callback writer/installer to decide > does he/she need a removable at runtime callback or not. > Though in that case, each installed callback might introduce extra > synchronization overhead and slowdown. >=20 > Konstantin Ananyev (3): > ethdev: introduce eth_queue_local > ethdev: make it safe to remove rx/tx callback at runtime > doc: ethdev ABI change deprecation notice >=20 > doc/guides/rel_notes/deprecation.rst | 5 + > lib/librte_ether/rte_ethdev.c | 390 ++++++++++++++++++++++-------= ------ > lib/librte_ether/rte_ethdev.h | 174 ++++++++++++---- > 3 files changed, 387 insertions(+), 182 deletions(-) >=20 > -- > 2.13.5