From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f176.google.com (mail-wj0-f176.google.com [209.85.210.176]) by dpdk.org (Postfix) with ESMTP id 6ED694A59 for ; Fri, 2 Dec 2016 00:50:33 +0100 (CET) Received: by mail-wj0-f176.google.com with SMTP id xy5so218354437wjc.0 for ; Thu, 01 Dec 2016 15:50:33 -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=KTKlpWrZXMxQvEXopUJPJpAa4m0HOhxl3VhQWlSrCOk=; b=yzrvFwEDtwozSaARCoRkaqADsxTRg2KCdf6C/5ia1xGCabr+xtToKZsUEmLu9GGIaf Q9LBKMcHh3wR1GrENg/9qiNY8P1ng4HCRmPIISlTycfUK0flNKdZck8GMHHlUvdm7Tsr 9WdDk7GFPbQITM2cmhfRJN8r4+PCk8dtvFCCYyb9NFSa3zDYACRpbR6C1b7d8eDtuoqS xD3bYDKW1O+e0+6V6wrMXoT+GOz4zf5kH/yK9v8c2Uc+X1Y3I9tmSCBGBGEZ22Huw4MB ZKDIqY7NVy21SpZfYeNagX9WzBemlvX/WIahh8G6WEiRzsU/nZ0UXVPGi/aMUtwt/H3B SEAQ== 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=KTKlpWrZXMxQvEXopUJPJpAa4m0HOhxl3VhQWlSrCOk=; b=DqskzEZqCBhpRWJZOYw8m9/1/Gz+u2Z9x91wJku1Im8gh6Xo6M0IR8SddX5UGwWxh2 iJHUmhixfLyv8wj5T1beV690tL3yCuysmjK/NSH0SX0dYxGaOaETILvkPzcTmzreW6wv zo5nQMmjIH/kJKlKK4IKRVp4V0ycX7q/uHpb4Vg3IZsqrIh4KX3mAd8SKKQn4lty1wWZ cafTvPvUjwPdXyovgWRWpmCyJGI2A/qezdbn12Z1kID1Xs29g3KYlqv7yZDjJcpBLDsG AvmLG43af1kC7FK6w3RCKwiaZ8wnhs8EcfiTiOwKP6ShaqNl5C5770dDUdisb2Epk35M 55dA== X-Gm-Message-State: AKaTC00jDVwWlt0DRzZlYHgDQSCJKd+1tdWWc3aJljvRHecHWJ3dY/nkWuAt6tWImM169UrJ X-Received: by 10.194.86.104 with SMTP id o8mr35343275wjz.196.1480636233127; Thu, 01 Dec 2016 15:50:33 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id b3sm2611516wjy.40.2016.12.01.15.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 15:50:32 -0800 (PST) From: Thomas Monjalon To: "Kulasek, TomaszX" Cc: dev@dpdk.org, "Ananyev, Konstantin" , olivier.matz@6wind.com, "Richardson, Bruce" Date: Fri, 02 Dec 2016 00:50:31 +0100 Message-ID: <4969291.OX96oIJoy2@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F57CDE@IRSMSX102.ger.corp.intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <2505996.o0gdCe9Hsd@xps13> <3042915272161B4EB253DA4D77EB373A14F57CDE@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 23:50:33 -0000 2016-12-01 22:31, Kulasek, TomaszX: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 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. > > It is not to be turned on/off whatever someone wants, but only and only for the case, when platform developer knows, that his platform doesn't need this callback, so, he may turn off it and then save some performance (this option is per target). How may he know? There is no comment in the config file, no documentation. > For this case, the behavior of tx_prepare will be exactly the same when it is turned on or off. If is not the same, there's no sense to turn it off. There were long topic, where we've tried to convince you, that it should be turned on for all devices. Really? You tried to convince me to turn it on? No you were trying to convince Jerin. I think it is a wrong idea to allow disabling this function. I didn't comment in first discussion because Jerin told it was really important for small hardware with fixed NIC, and I thought it would be implemented in a way the application cannot be misleaded. The only solution I see here is to add some comments in the configuration file, below the #else and in the doc. Have you checked doc/guides/prog_guide/poll_mode_drv.rst?