From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id E6A005F5F for ; Wed, 21 Mar 2018 10:55:09 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 02:55:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,339,1517904000"; d="scan'208";a="39880181" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by fmsmga001.fm.intel.com with ESMTP; 21 Mar 2018 02:55:07 -0700 Received: from irsmsx110.ger.corp.intel.com ([169.254.15.211]) by IRSMSX109.ger.corp.intel.com ([169.254.13.170]) with mapi id 14.03.0319.002; Wed, 21 Mar 2018 09:55:06 +0000 From: "Pattan, Reshma" To: "Tan, Jianfeng" , "dev@dpdk.org" Thread-Topic: [PATCH] pdump: change to use generic multi-process channel Thread-Index: AQHTs8neFUbu0i76/UiWNBgJqZR5tqPZYd+ggACvHoCAAHoB0A== Date: Wed, 21 Mar 2018 09:55:06 +0000 Message-ID: <3AEA2BF9852C6F48A459DA490692831F2A2B8602@irsmsx110.ger.corp.intel.com> References: <1520175844-55443-1-git-send-email-jianfeng.tan@intel.com> <3AEA2BF9852C6F48A459DA490692831F2A2B82D6@irsmsx110.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] [PATCH] pdump: change to use generic multi-process channel 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: Wed, 21 Mar 2018 09:55:10 -0000 Hi, > -----Original Message----- > From: Tan, Jianfeng > Sent: Wednesday, March 21, 2018 2:28 AM > To: Pattan, Reshma ; dev@dpdk.org > Subject: RE: [PATCH] pdump: change to use generic multi-process channel >=20 Hi, > > 1) I feel ABI breakage has to be addressed first for change in > rte_pdump_init() . > > 2)ABI notice for removal of the rte_pdump_set_socket_dir() and then > remove it completely . >=20 > This patch itself does not break any ABI. It just puts parameters of > rte_pdump_init() not used. And make rte_pdump_set_socket_dir() as a > dummy function. >=20 So, for current release you just mark parameters unused and functions set t= o dummy, in future release you announce=20 ABI breakage by removing them completely? If that is agreed plan I don't ha= ve any issues. > > 3)Need to do cleanup of the code app/dpdk-pdump. >=20 > Yes, I understand it's a normal process to announce deprecation firstly, = and > then do the change. >=20 > But here is the thing, with generic mp introduced, we will not be compati= ble > with DPDK versions. > So we want to unify the use of generic mp channel in this release for vfi= o, > pdump, vdev, memory rework. > And in fact, ABI/API changes could be delayed to later releases. So, you want to remove unnecessary socket related code from dpdk-pdump in = future release itself? Kind of making sense.=20 But dpdk-pdump tool has socket path related command line options which use= r still can pass on, isn't it kind of confusion we creating w.r.t Internal design and usage?=20 >=20 > > 4)After all the changes we need to make sure dpdk-pdump works fine > > without breaking the functionality, validation team should be able to h= elp. >=20 > I have done a simple test of pdump. Can you suggest where can I get the > comprehensive test cases? >=20 Ok, if you have verified and observed packets are been captured successfull= y, that is good enough. Thanks, Reshma