From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 66209292D for ; Fri, 28 Oct 2016 14:59:46 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP; 28 Oct 2016 05:59:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,410,1473145200"; d="scan'208";a="184956823" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga004.fm.intel.com with ESMTP; 28 Oct 2016 05:59:44 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.177]) by irsmsx110.ger.corp.intel.com ([163.33.3.25]) with mapi id 14.03.0248.002; Fri, 28 Oct 2016 13:59:43 +0100 From: "Ananyev, Konstantin" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation Thread-Index: AQHSL4iZ5WiAYkWG4EqB+e9ej9GU7qC8ViAAgAAd2uD///MYgIAAEtTQ///3j4CAAUaGcIAABwTA///9cAAAAoNNgA== Date: Fri, 28 Oct 2016 12:59:42 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0CED77@irsmsx105.ger.corp.intel.com> References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB9772583F0CEC55@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0CEC6E@irsmsx105.ger.corp.intel.com> <4589776.b4NVqTvzOG@xps13> In-Reply-To: <4589776.b4NVqTvzOG@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 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation 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: Fri, 28 Oct 2016 12:59:46 -0000 >=20 > 2016-10-28 11:34, Ananyev, Konstantin: > > > > 2016-10-27 16:24, Ananyev, Konstantin: > > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > > 2016-10-27 15:52, Ananyev, Konstantin: > > > > > > > > 2016-10-26 14:56, Tomasz Kulasek: > > > > > > > > > --- a/config/common_base > > > > > > > > > +++ b/config/common_base > > > > > > > > > +CONFIG_RTE_ETHDEV_TX_PREP=3Dy > > > > > > > > > > > > > > > > We cannot enable it until it is implemented in every driver= s. > > > > > > > > > > > > > > Not sure why? > > > > > > > If tx_pkt_prep =3D=3D NULL, then rte_eth_tx_prep() would just= act as noop. > > > > > > > Right now it is not mandatory for the PMD to implement it. > > > > > > > > > > > > If it is not implemented, the application must do the preparati= on by itself. > > > > > > From patch 6: > > > > > > " > > > > > > Removed pseudo header calculation for udp/tcp/tso packets from > > > > > > application and used Tx preparation API for packet preparation = and > > > > > > verification. > > > > > > " > > > > > > So how does it behave with other drivers? > > > > > > > > > > Hmm so it seems that we broke testpmd csumonly mode for non-intel= drivers.. > > > > > My bad, missed that part completely. > > > > > Yes, then I suppose for now we'll need to support both (with and = without) code paths for testpmd. > > > > > Probably a new fwd mode or just extra parameter for the existing = one? > > > > > Any other suggestions? > > > > > > > > Please think how we can use it in every applications. > > > > It is not ready. > > > > Either we introduce the API without enabling it, or we implement it > > > > in every drivers. > > > > > > I understand your position here, but just like to point that: > > > 1) It is a new functionality optional to use. > > > The app is free not to use that functionality and still do the p= reparation itself > > > (as it has to do it now). > > > All existing apps would keep working as expected without using th= at function. > > > Though if the app developer knows that for all HW models he plans= to run on > > > tx_prep is implemented - he is free to use it. > > > 2) It would be difficult for Tomasz (and other Intel guys) to imp= lement tx_prep() > > > for all non-Intel HW that DPDK supports right now. > > > We just don't have all the actual HW in stock and probably adequ= ate knowledge of it. > > > So we depend here on the good will of other PMD mainaners/develop= ers to implement > > > tx_prep() for these devices. > > > From other side, if it will be disabled by default, then, I think= , > > > PMD developers just wouldn't be motivated to implement it. > > > So it will be left untested and unused forever. > > > > Actually as another thought: > > Can we have it enabled by default, but mark it as experimental or so? > > If memory serves me right, we've done that for cryptodev in the past, n= o? >=20 > Cryptodev was a whole new library. > We won't play the game "find which function is experimental or not". >=20 > We should not enable a function until it is fully implemented. >=20 > If the user really understands that it will work only with few drivers > then he can change the build configuration himself. > Enabling in the default configuration is a message to say that it works > everywhere without any risk. > It's so simple that I don't even understand why I must argue for. >=20 > And by the way, it is late for 16.11. Ok, I understand your concern about enabling it by default and testpmd brea= kage, but what else you believe is not ready?=20 > I suggest to integrate it in the beginning of 17.02 cycle, with the hope > that you can convince other developers to implement it in other drivers, > so we could finally enable it in the default config. Ok, any insights then, how we can convince people to do that? BTW, it means then that tx_prep() should become part of mandatory API to be implemented by each PMD doing TX offloads, right? =20 >=20 > Oh, and I don't trust that nobody were thinking that it would break testp= md > for non-Intel drivers. Well, believe it or not, but yes, I missed that one. I think I already admitted that it was my fault, and apologized for that. But sure, it is your choice to trust me here or not. Konstantin