From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH 1/2] net/ena: convert to new Tx offloads API Date: Thu, 18 Jan 2018 14:49:00 +0000 Message-ID: <16b16b11-32b5-aeae-353e-a81611d42dd6@intel.com> References: <1516103563-9275-1-git-send-email-rk@semihalf.com> <1516103563-9275-2-git-send-email-rk@semihalf.com> <40a3b871-094f-0873-789d-d24a5ad4dc19@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "mw@semihalf.com" , "mk@semihalf.com" , "gtzalik@amazon.com" , "evgenys@amazon.com" , "matua@amazon.com" , "igorch@amazon.com" To: Shahaf Shuler , Rafal Kozik , "dev@dpdk.org" Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 9F9401B2F0 for ; Thu, 18 Jan 2018 15:49:03 +0100 (CET) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 1/18/2018 6:26 AM, Shahaf Shuler wrote: > Wednesday, January 17, 2018 8:58 PM, Ferruh Yigit : >>> Here is it better to check also the ETH_TXQ_FLAGS_IGNORE. >>> If application has not yet moved to the new API, then it won't set any port >> Tx offloads. So for old applications, the >> ena_are_tx_queue_offloads_allowed is not necessary. >> >> But ethdev layer will set the offloads if ETH_TXQ_FLAGS_IGNORE is missing, >> can't PMD always only rely on tx_conf->offloads ? > > This is to address PMD which moved to the new offloads API but the application still uses the old offloads API. > > There are many Tx offloads which are per port (as there is a burst function per port, and not per queue). However the application will not set any offload on the device configuration rather only in the queue setup. The PMD can fail the setup function on such case, as per-port offload is requested on the queue setup without being requested first on the device configuration. I see, dev->data->dev_conf.txmode.offloads will be empty for old applications which ena_are_tx_queue_offloads_allowed() compares against txq->offload. So I agree, thanks.