From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 86F74101B for ; Mon, 12 Mar 2018 17:59:42 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2018 09:59:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,462,1515484800"; d="scan'208";a="41292314" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.62]) ([10.237.221.62]) by orsmga002.jf.intel.com with ESMTP; 12 Mar 2018 09:59:40 -0700 To: Shahaf Shuler , Mordechay Haimovsky , "pascal.mazon@6wind.com" Cc: "dev@dpdk.org" References: <1515601248-39458-2-git-send-email-motih@mellanox.com> <1516197874-133169-1-git-send-email-motih@mellanox.com> <1516197874-133169-2-git-send-email-motih@mellanox.com> <95d434f5-438a-19a7-1227-18c1230201c0@intel.com> From: Ferruh Yigit Message-ID: <8973efd1-ec77-2e51-0516-634ab878bb1c@intel.com> Date: Mon, 12 Mar 2018 16:59:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx offloads API 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: Mon, 12 Mar 2018 16:59:43 -0000 On 3/12/2018 2:20 PM, Shahaf Shuler wrote: > > > --Shahaf > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit >> Sent: Friday, March 2, 2018 11:44 PM >> To: Mordechay Haimovsky ; >> pascal.mazon@6wind.com >> Cc: dev@dpdk.org; Shahaf Shuler >> Subject: Re: [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx offloads API >> >> On 1/17/2018 2:04 PM, Moti Haimovsky wrote: >>> Ethdev Rx offloads API has changed since: >>> commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") This >>> commit adds support for the new Rx offloads API. >>> >>> Signed-off-by: Moti Haimovsky >> >> <...> >> >>> +static bool >>> +tap_rxq_are_offloads_valid(struct rte_eth_dev *dev, uint64_t >>> +offloads) { >>> + uint64_t port_offloads = dev->data->dev_conf.rxmode.offloads; >>> + uint64_t queue_supp_offloads = tap_rx_offload_get_queue_capa(); >>> + uint64_t port_supp_offloads = tap_rx_offload_get_port_capa(); >>> + >>> + if ((offloads & (queue_supp_offloads | port_supp_offloads)) != >>> + offloads) >>> + return false; >>> + if ((port_offloads ^ offloads) & port_supp_offloads) >>> + return false; >> >> Hi Moti, >> >> I am getting following error when tried to use tap with bonding: >> "Rx queue offloads 0x0 don't match port offloads 0x1000 or supported >> offloads 0x300e" >> >> What is the intention here? I guess it tries to be sure requested queue >> offloads is subsets of port_offloads and offload_capability. >> If so not requesting any queue offload should be valid, isn't it? > > > Port offload should be enabled on both port and queue configuration. This is part of the documentation [1], section "8.4.7.1. Per-Port and Per-Queue Offloads" > On the above case, you try to enable the DEV_RX_OFFLOAD_CRC_STRIP on the port without enabling it on the queues. I guess DEV_RX_OFFLOAD_CRC_STRIP is reported by the tap PMD as port (and not queue) offload. > > To answer some question asked privately by Ferruh: >> Why queue offload values should be set to enable per-port offload? I think this is wrong. We don't do queue offload at all, don't use that value, but this suggest that value should be some specific value to work, why? > > The logic behind it was to make the offloads enablement more explicit. > Consider port offload is set on device configuration, but not set on the queue. there is an uncertainty whether the application wanted to "not enable" this offload or it was just not set (like in your case). > > There other way around also makes sense: if offload was set on the port configuration then it is applied to each of the queues, with no way for the application to disable it through the queue configuration. > > The current API choose option #1, we can discuss to do small change to move to #2. There are some devices supports queue level offloads and there are some devices supports port level offloads. Values queue offload = 0x0 and port offload = 0x1000, for the device that support queue level offloads may mean disabling all offloads for that specific queue and this is valid value. For the device that support port level offloads this is an error. What about using "rx/tx_queue_offload_capa" field to help application to detect if device supports queue level or port level offloads? If device reports 0x0 "rx_queue_offload_capa", application will know device doesn't support queue level offloads and PMD just ignore all provided queue offloads. If device reports a "rx_queue_offload_capa" other than 0x0, app will know that device _supports_ queue offloads and will set offloads according and PMD will verify and apply queue specific offloads according. For above tap specific case, is tap PMD supports queue specific offloads? And there should be some restrictions on offloading values: 1- requested port offloads should be subset of supported port offloads 2- supported queue offloads should be subset of supported port offloads 3- requested queue offloads should be subset of supported queue offloads And since these information is part of dev_info, these can be managed in the ethdev layer, instead of checked in each PMD (as done in tap). According above, would you mind walk-trough how application can set offloads: A) New application that implements new offloading APIs: - Get dev_info - Configure Rx/Tx offloads based on rx_offload_capa / tx_offload_capa - If rx_queue_offload_capa / tx_queue_offload_capa is other than 0, setup RxQ / TxQ offloads based on these values. - If rx_queue_offload_capa / tx_queue_offload_capa is 0, queue level offlaods are not supported by this device, ignore offloads during RxQ / TxQ setup. All look OK here. B) Old application with old offloading API - Get dev_info, which provides only rx_offload_capa, tx_offload_capa and txq_flags - set rte_eth_rxmode->bitfield_values ==> ethdev will convert them to port level Rx offloads. - port level offloads are empty!! - ethdev will set queue level Rx offloads to be same as port level Rx offloads. - ethdev will set txq_flags values for Tx offloads to queue level Tx offloads. Things should work well for PMDs with old offloading API. For the PMDs that support new offloading API, port level Tx offload values are missing and Queue level and Port level Tx offloads mismatch. Am I missing something here, if not how can we solve this issue in PMDs? > >> >> I believe other way around makes sense, to be able to set queue offload param, device should announce that offloading as supported. Queue is subset of the device, why you ignore device offload param to set queue offload param? >> >> What makes sense to me: >> "queue offload" is subset of "device offload" is subset of "device supported offload" > > > > > [1] > http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html > > >> >> <...>