From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0BD6E2BF9 for ; Tue, 1 Nov 2016 13:57:20 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 01 Nov 2016 05:57:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,579,1473145200"; d="scan'208";a="780823408" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by FMSMGA003.fm.intel.com with ESMTP; 01 Nov 2016 05:57:19 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.177]) by IRSMSX152.ger.corp.intel.com ([169.254.6.24]) with mapi id 14.03.0248.002; Tue, 1 Nov 2016 12:57:18 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation Thread-Index: AQHSL4iZ5WiAYkWG4EqB+e9ej9GU7qC8ViAAgAAd2uD///MYgIAAEtTQ///3j4CAAUaGcIAABwTA///9cAAAAoNNgAAAPlqAAMfhl1A= Date: Tue, 1 Nov 2016 12:57:17 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0CF990@irsmsx105.ger.corp.intel.com> References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com> <4589776.b4NVqTvzOG@xps13> <2601191342CEEE43887BDE71AB9772583F0CED77@irsmsx105.ger.corp.intel.com> <2177010.quNaxrZShx@xps13> In-Reply-To: <2177010.quNaxrZShx@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: Tue, 01 Nov 2016 12:57:21 -0000 Hi Thomas, =20 > > > I suggest to integrate it in the beginning of 17.02 cycle, with the h= ope > > > that you can convince other developers to implement it in other drive= rs, > > > so we could finally enable it in the default config. > > > > Ok, any insights then, how we can convince people to do that? >=20 > You just have to explain clearly what this new feature is bringing > and what will be the future possibilities. >=20 > > BTW, it means then that tx_prep() should become part of mandatory API > > to be implemented by each PMD doing TX offloads, right? >=20 > Right. > The question is "what means mandatory"? For me "mandatory" here would mean that: - if the PMD supports TX offloads AND - if to be able use any of these offloads the upper layer SW would have to= : - modify the contents of the packet OR - obey HW specific restrictions then it is a PMD developer responsibility to provide tx_prep() that would = implement expected modifications of the packet contents and restriction checks. Otherwise, tx_prep() implementation is not required and can be safely set t= o NULL. =20 Does it sounds good enough to everyone? > Should we block some patches for non-compliant drivers? If we agree that it should be a 'mandatory' one - and patch in question bre= aks that requirement, then probably yes. > Should we remove offloads capability from non-compliant drivers? Do you mean existing PMDs? Are there any particular right now, that can't work properly with testpmd c= sumonly mode? Konstantin =20