From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 8CE4458EF for ; Thu, 1 Dec 2016 20:52:24 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id a197so309561654wmd.0 for ; Thu, 01 Dec 2016 11:52:24 -0800 (PST) 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=waHVskZHaW5wf1PjMuqL4PavglIswu40ovSvN6Ps5pI=; b=n9/uQTxMNnLTe1IVu/A68LcnB+ArIz6kj3V+DuPRo0jmiqvthwonetWyBXVmcMhXxd 2U8lHMsvURpCLbKSym8ap34hBzeK9kWWFUVze4hDqi5AZav3f2hskvZLorCJg/3C24Fw 8VcrqKZ132D8uGxIyUfK27fzOKHjM/P8V3uT+/GiIXPe9Gbi60drKRozfSouXpMF6s8j gkh8xv8MjYUce6Jph8rvk4YH+h6q85fDqAXCzWc/IRCZzsCq/aHMY8OQGryHWJgzuJB0 FDv86wu+mnaV2AZwt1C0husnWiOXS+t3T0cVyvYgbmyfcAwtTD8R0NbWqMUyeEpSWHIk aNzQ== 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=waHVskZHaW5wf1PjMuqL4PavglIswu40ovSvN6Ps5pI=; b=ZPATfwTLUuXAv76KWcnidDeK9SX7Hvo5+YmyEq62lh8U/kwwJCPPp+E3CU/eh6gLJ4 q/KsLpQ9xPR2w8I4H5cz1SSHeZCvf+n1EI/ZWIgA/YhJE1hMazmd1I1plela9r41sBom yi3CrUbdlbsBy9jgV1sV9/GSXhqhShQzFdLouq0IzKjsZbMljlbVuicKEtzSvvD6C92F iVIS9YkTcki9cTWpUgiK2ihxQqfajOcWw4v/NXJnEZADfuyGpjAo+5ZKUOX9CmliXigh MnFszKRY1T5+/6iQZewPjp93wFbFY/61LSlsHjKCXqYTQ757K5lv6ID87hM6rD6bbnSU YwCA== X-Gm-Message-State: AKaTC02Ks/5S+lNeMp38efBZqwUnAZd2K7XpzQkkdcQX8LO2EN4bkXryOegQopuP0Y9rMZCc X-Received: by 10.28.17.205 with SMTP id 196mr34314440wmr.78.1480621944263; Thu, 01 Dec 2016 11:52:24 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id j6sm1853558wjk.25.2016.12.01.11.52.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 11:52:23 -0800 (PST) From: Thomas Monjalon To: "Kulasek, TomaszX" Cc: dev@dpdk.org, "Ananyev, Konstantin" , olivier.matz@6wind.com, "Richardson, Bruce" Date: Thu, 01 Dec 2016 20:52:22 +0100 Message-ID: <2505996.o0gdCe9Hsd@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F57CAE@IRSMSX102.ger.corp.intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <1734448.0id6dCbsBT@xps13> <3042915272161B4EB253DA4D77EB373A14F57CAE@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 19:52:24 -0000 2016-12-01 19:20, Kulasek, TomaszX: > Hi Thomas, > > Sorry, I have answered for this question in another thread and I missed about this one. Detailed answer is below. Yes you already gave this answer. And I will continue asking the question until you understand it. > > 2016-11-28 11:54, Thomas Monjalon: > > > Hi, > > > > > > 2016-11-23 18:36, Tomasz Kulasek: > > > > --- a/config/common_base > > > > +++ b/config/common_base > > > > @@ -120,6 +120,7 @@ CONFIG_RTE_MAX_QUEUES_PER_PORT=1024 > > > > CONFIG_RTE_LIBRTE_IEEE1588=n > > > > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16 > > > > CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y > > > > +CONFIG_RTE_ETHDEV_TX_PREPARE=y > > > > > > Please, remind me why is there a configuration here. > > > It should be the responsibility of the application to call tx_prepare > > > or not. If the application choose to use this new API but it is > > > disabled, then the packets won't be prepared and there is no error code: > > > > > > > +#else > > > > + > > > > +static inline uint16_t > > > > +rte_eth_tx_prepare(__rte_unused uint8_t port_id, __rte_unused > > uint16_t queue_id, > > > > + __rte_unused struct rte_mbuf **tx_pkts, uint16_t > > > > +nb_pkts) { > > > > + return nb_pkts; > > > > +} > > > > + > > > > +#endif > > > > > > So the application is not aware of the issue and it will not use any > > > fallback. > > tx_prepare mechanism can be turned off by compilation flag (as discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory dereference and check can have significant impact on performance). > > Jerin observed that on some architectures (e.g. low-end ARM with embedded NIC), just reading and comparing 'dev->tx_pkt_prepare' may cause significant performance drop, so he proposed to introduce this configuration flag to provide real NOOP when tx_prepare functionality is not required, and can be turned on based on the _target_ configuration. > > For other cases, when this flag is turned on (by default), and tx_prepare is not implemented, functional NOOP is used based on comparison (dev->tx_pkt_prepare == NULL). So if the application call this function and if it is disabled, it simply won't work. Packets won't be prepared, checksum won't be computed. I give up, I just NACK.