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 6A0C72BBE for ; Mon, 11 Jul 2016 12:40:00 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP; 11 Jul 2016 03:39:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,346,1464678000"; d="scan'208";a="1019368657" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga002.fm.intel.com with ESMTP; 11 Jul 2016 03:39:27 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.51]) by IRSMSX152.ger.corp.intel.com ([169.254.6.247]) with mapi id 14.03.0248.002; Mon, 11 Jul 2016 11:39:26 +0100 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: "Lu, Wenzhuo" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] specific driver API - was bypass code cleanup Thread-Index: AQHR213hVAXlv6HAB0OVU0ycnLgow6ATB9Fw Date: Mon, 11 Jul 2016 10:39:26 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B7C84A@irsmsx105.ger.corp.intel.com> References: <1468218079-8064-1-git-send-email-wenzhuo.lu@intel.com> <1927507.Pj5eqIlGbv@xps13> <2601191342CEEE43887BDE71AB97725836B7C7F1@irsmsx105.ger.corp.intel.com> <10057084.veiWr8cPc7@xps13> In-Reply-To: <10057084.veiWr8cPc7@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] specific driver API - was 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 10:40:00 -0000 > > > > > 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 in > > > > > the application. > > > > > > > > Hmm, isn't that what we were trying to get rid of in last few years= ? > > > > HW specific stuff? > > > > > > Yes exactly. > > > I have the feeling the bypass API is specific to ixgbe. Isn't it? > > > > As far as I know, yes. > > > > > 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 devi= ce, > > the thing we were trying to get rid of in last few releases, no? >=20 > Not really. If an application requires the bypass feature, we can assume > it will be used only on ixgbe NICs. Bypass HW doesn't present on all ixgbe devices. Only few specific models have that functionality. So we still to provide and API for user to query is that functionality is s= upported or not, user still has to make a decision based on HW id.=20 > Having some generic APIs helps to deploy DPDK applications on heterogeous > machines. But if an application rely on something hardware specific, ther= e > is no benefit of using a "fake generic layer" I guess. Ok, what is your definition of 'heterogeous machines' then? Let say today, as I know, only i40e and ixgbe can do HW mirroring of the tr= affic. Is that generic enough, or not? I suppose we can find huge number of examples, when functionality differes between different HW models. As I remember that was discussed a while ago, and generic conclusion was: avoid device specific API exposed to the application layer.=20 >=20 > > > 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 communic= ate > > about HW specific features. > > Might be a bypass I a good candidate to be moved into this ioctl() thin= g... >=20 > I don't see how making an ioctl-like would be better than directly includ= ing > a specific header. User and application writer don't have to guess on what device his code wil= l work. He can just query what ioctl IDs that device support, and then use the supp= orted ones. >=20 > > But I suppose it's too late for 16.07 to start such big changes. >=20 > Of course yes. Ok, then I misunderstood you here. >=20 > > If you don't like bypass API to be a generic one, my suggestion would b= e > > to leave it as it is for 16.07, and start a discussion what it should l= ook like > > for 16.11. >=20 > That's what we are doing here. > I've changed the title to give a better visibility to the thread. Ok, thanks. Konstantin