From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id B8B272C12 for ; Tue, 27 Mar 2018 03:26:08 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2018 18:26:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,366,1517904000"; d="scan'208";a="37044770" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 26 Mar 2018 18:26:07 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 26 Mar 2018 18:26:06 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 26 Mar 2018 18:26:06 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.235]) by shsmsx102.ccr.corp.intel.com ([169.254.2.80]) with mapi id 14.03.0319.002; Tue, 27 Mar 2018 09:26:05 +0800 From: "Tan, Jianfeng" To: "Pattan, Reshma" , "dev@dpdk.org" Thread-Topic: [PATCH] pdump: change to use generic multi-process channel Thread-Index: AQHTs8ndG6L72y5Ol0+dtwgmKVSfbqPY5dyAgAEjEiD///7DAIAJY5YA Date: Tue, 27 Mar 2018 01:26:04 +0000 Message-ID: References: <1520175844-55443-1-git-send-email-jianfeng.tan@intel.com> <3AEA2BF9852C6F48A459DA490692831F2A2B82D6@irsmsx110.ger.corp.intel.com> <3AEA2BF9852C6F48A459DA490692831F2A2B8602@irsmsx110.ger.corp.intel.com> In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F2A2B8602@irsmsx110.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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: Tue, 27 Mar 2018 01:26:09 -0000 > -----Original Message----- > From: Pattan, Reshma > Sent: Wednesday, March 21, 2018 5:55 PM > To: Tan, Jianfeng; dev@dpdk.org > Subject: RE: [PATCH] pdump: change to use generic multi-process channel >=20 > Hi, >=20 > > -----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, >=20 > > > 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 . > > > > 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= to > dummy, in future release you announce > ABI breakage by removing them completely? If that is agreed plan I don't > have any issues. Actually, as you commented, we can announce the deprecation with this patch= . >=20 > > > 3)Need to do cleanup of the code app/dpdk-pdump. > > > > Yes, I understand it's a normal process to announce deprecation firstly= , and > > then do the change. > > > > But here is the thing, with generic mp introduced, we will not be > compatible > > with DPDK versions. > > So we want to unify the use of generic mp channel in this release for v= fio, > > pdump, vdev, memory rework. > > And in fact, ABI/API changes could be delayed to later releases. >=20 > So, you want to remove unnecessary socket related code from dpdk-pdump > in future release itself? Kind of making sense. > But dpdk-pdump tool has socket path related command line options which > user still can pass on, isn't it kind of confusion we creating w.r.t > Internal design and usage? AFAIK, these options do not affect anything with this patch even they are s= et. How about printing a warning saying that these options will be deprecat= ed and take no effect now? I'll send a v2 for your review. Thanks, Jianfeng >=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= help. > > > > 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 successfu= lly, > that is good enough. >=20 > Thanks, > Reshma