From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 09AC82BD2 for ; Fri, 28 Oct 2016 14:23:50 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id n67so110468124wme.1 for ; Fri, 28 Oct 2016 05:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=sKPNsGKeVE8jTDJ8rz3HVuq6ArBFnFCX+uDMw1+Gq+M=; b=GByUf6a2+wZrXCXRgUUafHBEZMC+SNbknANFWcdjG3EzEyCrp4Zwek7c729iH/PyRK i7erOVQGTSXfpBi9qCgkZ1dTTPTR5Vcv065axUv2yaWUfYGe/gFOys4wgEGi+o/Hd49R i1nM9gyDEUalMeiXrknXGjVFsjhK3SAw74OHMNHWFdLT1L4OXeeHrB4kPMSVPiTaWJ6T 9QSYUkSlw0hoqDde6lhHJwmG9oqGyHAKFZnj/FQD1defP8o6UCImJvP1CwXgyXJoBcUt o+mk2soh2NQweNIjH/ld+9cyk6RpF/pllcN8YcsTqb+n0eE/ysEX7mSm82qg8zzgNOXz PAIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=sKPNsGKeVE8jTDJ8rz3HVuq6ArBFnFCX+uDMw1+Gq+M=; b=GzCXIdOZo+UvIHNsZ1DnYzgynk+QUqrOwcvJTLIfdsWHSHQu/DphIwaweRtNMPotIF PwfRc2iim6Cg5S6rgCzxXpAZQOvKcZ918GIGBLSMUhGOvsyHOJW72YZ36HQ0or8Rw/T5 pK1jfgcYhPdNTnFZQ/26G860ThsWkG7hT1F5S227iMNIQsAYyDqmmkgrFca5iuQ2XNai a6sVw1njdeSOdzwJ8NAJ4bu2GJv7fbIzi7RyXR6R65CiIWRSj7BVIy7w73aN6cVCzFbS igeAosnihyPSNjht9Ph+ufhpti+vQpxLfgl2rzwVU/56aGbzzeab2aw6x9skhLgjSWBk Mtzg== X-Gm-Message-State: ABUngvcbnIx+YTRV+JdsKnqU8GTgu5hiZjGrVaCi+Em2wVUrb+LXzz93YRDx3NNa2hH+aekC X-Received: by 10.28.6.137 with SMTP id 131mr3280692wmg.49.1477657429736; Fri, 28 Oct 2016 05:23:49 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id e5sm8681266wma.10.2016.10.28.05.23.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 05:23:48 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Date: Fri, 28 Oct 2016 14:23:48 +0200 Message-ID: <4589776.b4NVqTvzOG@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0CEC6E@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:23:50 -0000 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=y > > > > > > > > > > > > > > We cannot enable it until it is implemented in every drivers. > > > > > > > > > > > > Not sure why? > > > > > > If tx_pkt_prep == 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 preparation 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 preparation itself > > (as it has to do it now). > > All existing apps would keep working as expected without using that 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 implement 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 adequate knowledge of it. > > So we depend here on the good will of other PMD mainaners/developers 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, no? Cryptodev was a whole new library. We won't play the game "find which function is experimental or not". We should not enable a function until it is fully implemented. 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. And by the way, it is late for 16.11. 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. Oh, and I don't trust that nobody were thinking that it would break testpmd for non-Intel drivers.