From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id EFE42682E for ; Thu, 28 Aug 2014 16:27:32 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 28 Aug 2014 07:31:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,418,1406617200"; d="scan'208";a="594581965" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 28 Aug 2014 07:31:38 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 28 Aug 2014 07:31:38 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 28 Aug 2014 07:31:38 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 22:31:35 +0800 From: "Wu, Jingjing" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl Thread-Index: AQHPwZyfQaobU/kb/0yOC0EzU412AZvj+3OAgAFZloD///7jAIAAq21Q//+N3wCAAIdxQA== Date: Thu, 28 Aug 2014 14:31:34 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8ADC26A@SHSMSX104.ccr.corp.intel.com> References: <1409105634-29980-1-git-send-email-jingjing.wu@intel.com> <1793573.SnjKVZ6loZ@xps13> <9BB6961774997848B5B42BEC655768F8ADC20D@SHSMSX104.ccr.corp.intel.com> <33553897.HNdRDVj5YS@xps13> In-Reply-To: <33553897.HNdRDVj5YS@xps13> 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 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:27:33 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, August 28, 2014 10:21 PM > To: Wu, Jingjing > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API > rx_classification_filter_ctl >=20 > 2014-08-28 13:39, Wu, Jingjing: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > I'm OK to change APIs but you should remove the old one, or at least, > > > implement your new API in existing drivers to allow deprecation of th= e > > > old API. > > > I think it would help if you start by doing ixgbe work and then apply= it > > > to i40e. > > > > > > > Yes, it will be perfect if we can use this new API to achieve flow dire= ctor > > setting all types of NICs. But the concern is downward compatibility. >=20 > In this case, cleanup is more important than compatibility. >=20 > > Users who is planning update DPDK version need to change their code > > to adapt such changes. >=20 > Yes, but we can keep deprecated function during 1 release. >=20 > > That's why we choose a new API instead of modifying current APIs. And > > Of course, the ideal plan is adding such XXX_ctl function in Ixgbe and > > Igb to moving smoothly without removing current APIs. >=20 > Yes >=20 > > > I don't think flow director is a specific feature. We shouldn't have > > > to care if port is i40e or ixgbe to setup flow director. > > > Is it possible to have a common API and maybe an inheritance of the > > > common structure with PMD specific fields? > > > > Yes, flow director is not a specific feature. Even ixgbe and i40 use th= e same > > name. But the context and key have much difference. That's why I called= it > > specific. > > > > Yes, it's a good idea about an inheritance of the common structure. I t= hink it > > may support new NIC integration in future. We can do it with the new AP= I > > architecture. But the concern is still how to be compatible with old ve= rsion. >=20 > There is no compatibility blocker here. > If we can keep deprecated functions a while, we'll do. Otherwise, just go= with > the new API. > I prefer we concentrate on good design rather than on compatibility. >=20 OK, now I have a rough understanding about your opinion, I guess there will= be lots of rework need to be done. I will try. Thanks for your explanation= . > Thanks > -- > Thomas Thanks Jingjing