From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id CB3BF2BBE for ; Mon, 11 Jul 2016 11:56:10 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 11 Jul 2016 02:56:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,345,1464678000"; d="scan'208";a="732475596" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by FMSMGA003.fm.intel.com with ESMTP; 11 Jul 2016 02:56:09 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.51]) by IRSMSX108.ger.corp.intel.com ([169.254.11.125]) with mapi id 14.03.0248.002; Mon, 11 Jul 2016 10:56:06 +0100 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: "Lu, Wenzhuo" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup Thread-Index: AQHR2zyQoa7N6FxX7EC8l93zLOeGLaASv5aAgAAfmiCAAAQxAIAAGOxA Date: Mon, 11 Jul 2016 09:56:06 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B7C7F1@irsmsx105.ger.corp.intel.com> References: <1468218079-8064-1-git-send-email-wenzhuo.lu@intel.com> <2092181.9Q4Kasxdod@xps13> <2601191342CEEE43887BDE71AB97725836B7C73C@irsmsx105.ger.corp.intel.com> <1927507.Pj5eqIlGbv@xps13> In-Reply-To: <1927507.Pj5eqIlGbv@xps13> Accept-Language: en-IE, 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] lib/librte_ether: bypass code cleanup 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: Mon, 11 Jul 2016 09:56:11 -0000 =20 > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > > > for bypass is a good idea at all. > > > I was thinking to totally remove it. > > > > Why to remove it? > > As I know there are people who use that functionality. > > > > > Maybe we can try to have a specific API by including ixgbe_bypass.h i= n > > > the application. > > > > Hmm, isn't that what we were trying to get rid of in last few years? > > HW specific stuff? >=20 > Yes exactly. > I have the feeling the bypass API is specific to ixgbe. Isn't it? As far as I know, yes. >=20 > As we will probably see other features specific to only one device. > Instead of adding a function in the generic API, I think it may be > saner to include a driver header. But that means use has to make decision based on HW id/type of the device, the thing we were trying to get rid of in last few releases, no? > Then if it appears to be used > in more devices, it can be generalized. > What do you think of this approach? We talked few times about introducing sort of ioctl() call, to communicate about HW specific features. Might be a bypass I a good candidate to be moved into this ioctl() thing... But I suppose it's too late for 16.07 to start such big changes. If you don't like bypass API to be a generic one, my suggestion would be to leave it as it is for 16.07, and start a discussion what it should look = like for 16.11.=20 Konstantin=20 =20 =20