From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 71FDE568A for ; Fri, 28 Oct 2016 12:22:25 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id n67so104399786wme.1 for ; Fri, 28 Oct 2016 03:22:25 -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=yMm2CykzOVWxzwP8Xz4LfekHTpvau3SDq+ln7K5BO7s=; b=fe+8Io1aJmSZmcp+mUFHYLcGZqoc+mJ6sUL/RAh4xh+C9Ov1RypPlt74vJZg4UhiAf MfFFeDygpjcj++mQB5vWfJVDCrRMJJMS3/WC5W0bMDKxs6B5sVSEOUvhq+WmxPDhns7g wYZnB22cuQwfMPNs9JfXdmLK1RCxi3df7FGajVNItA1mFw9CbawB3GD83vjodTzCmxqd CgZCkOlOieY0NRudQ6MRQL7aDEvfR/Xrk9U5iQXbRpILx0bxiVaRczMhLDW+sySRxIp/ b5tQKQX3X0Iz0bi1UTOZiLhjzsvNApV7xx5Ij3W4dbf/e2wE0bGPrj+gX9RKUBzVFpkE UF/Q== 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=yMm2CykzOVWxzwP8Xz4LfekHTpvau3SDq+ln7K5BO7s=; b=Qo0cWKgj8mtnk7PeklGKyTRVXkp2ZfPP5FuT+KrI0wQWFqAdjZcvze3o6DYmmlsdhM tqyOF9jLRjZvaGGSroGTYRPRNQHnvExEGTxvyIedU/efF/SCCflf53Kq9d8Lmly3RYpx 2x18Abp3x6nUHZo7JwnA/UDlE6RVkYzN0UOZ25OM9RuN6g1nRv33QcyaM701CrMgLlkW Ba8aLEfvj3xQhhKDMnNpdJYGmps/XLjr4Kn2hOXqF5ohCM0Jw0DpiE7qGyZTSYHoorIr 41Xfk9HtrOFWpOp9jvCS+yR1+6RptipAf+sOIjmZKQsNdjT0jTwwXs1WYL8QLNMj7gCp iXFQ== X-Gm-Message-State: ABUngvfJi1WS6IYjGaM6+5VHlCspxtWPkLS2QEiJDsHFmDygNKwPnMaLWWm9nxlXDoMwlaku X-Received: by 10.28.191.142 with SMTP id o14mr2732969wmi.124.1477650145205; Fri, 28 Oct 2016 03:22:25 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 18sm8146848wmr.5.2016.10.28.03.22.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 03:22:24 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" , "Kulasek, TomaszX" Date: Fri, 28 Oct 2016 12:22:23 +0200 Message-ID: <18243372.Y4s77Td6b4@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0CEAEE@irsmsx105.ger.corp.intel.com> References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com> <3042915272161B4EB253DA4D77EB373A14F45162@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0CEAEE@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 10:22:25 -0000 2016-10-28 10:15, Ananyev, Konstantin: > > From: 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? > > > > > > > I had sent txprep engine in v2 (http://dpdk.org/dev/patchwork/patch/15775/), but I'm opened on the suggestions. If you like it I can resent > > it in place of csumonly modification. > > I still not sure it is worth to have another version of csum... > Can we introduce a new global variable in testpmd and a new command: > testpmd> csum tx_prep > or so? > Looking at current testpmd patch, I suppose the changes will be minimal. > What do you think? No please no! The problem is not in testpmd. The problem is in every applications. Should we prepare the checksums or let tx_prep do it? The result will depend of the driver used.