From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AC532A04CC; Mon, 21 Sep 2020 13:05:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2437B1D8E8; Mon, 21 Sep 2020 13:05:23 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 06A931C20B; Mon, 21 Sep 2020 13:05:20 +0200 (CEST) IronPort-SDR: OoIlBmy+oQ+s07dA4uv5JGVhW3ARwtXHxIAeNzAaTtB6ngZ1xgbMByRV940UrdBWZXMTTcgt+s XeLtf0qIqZHQ== X-IronPort-AV: E=McAfee;i="6000,8403,9750"; a="157734877" X-IronPort-AV: E=Sophos;i="5.77,286,1596524400"; d="scan'208";a="157734877" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 04:05:17 -0700 IronPort-SDR: FQxGFBKv0SYM9OxFOXzqSHndrW0jEdLFqMT4CqYeldryywNmRbRquyxiJRlfQoE42qbxP0sU1M Nasmzy6+7org== X-IronPort-AV: E=Sophos;i="5.77,286,1596524400"; d="scan'208";a="308983153" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.217.64]) ([10.213.217.64]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 04:05:15 -0700 To: Lance Richardson Cc: Ajit Khaparde , Somnath Kotur , dev@dpdk.org, stable@dpdk.org References: <20200909155302.28656-1-lance.richardson@broadcom.com> <20200909155302.28656-3-lance.richardson@broadcom.com> From: Ferruh Yigit Message-ID: Date: Mon, 21 Sep 2020 12:05:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 02/12] net/bnxt: fix rxq/txq get information 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/18/2020 7:41 PM, Lance Richardson wrote: > On Fri, Sep 11, 2020 at 10:41 AM Ferruh Yigit wrote: >> >>> - qinfo->conf.rx_drop_en = 0; >>> + qinfo->conf.rx_drop_en = 1; >> >> Why 0 is wrong but 1 is correct? >> >> Technically 'rx_drop_en' is a user configuration, which is set via >> 'rte_eth_rx_queue_setup()' API. >> >> bnxt seems not honoring this config option at all. >> >> Based on HW capability, I think two things can be done, >> 1) Configure the HW based on config request, and return configured value in >> 'bnxt_rxq_info_get_op()'. see 'ixgbe'. >> >> 2) If HW is not configurable, check the value in 'rte_eth_rx_queue_setup()' >> a) return error if unsupported value requested. see 'sfc'. >> b) log a warning and overwrite the requested config with whatever supported. >> And for both a & b, return current config in the 'bnxt_rxq_info_get_op()' >> >>> qinfo->conf.rx_deferred_start = rxq->rx_deferred_start; >>> + qinfo->conf.offloads = dev->data->dev_conf.rxmode.offloads; >> > Hi Ferruh, > > Apologies, this somehow didn't make it to my inbox. > > I believe case (2) applies here, rx_drop_en is not currently configurable in hw, > so this change was intended to accurately report the effective value. I'm not > sure whether (2a) or (2b) would be better, but (2b) seems less likely to cause > issues for existing applications. > I guess (2a) may cause more issues with existing applications, applications previously running without problem may now start failing if PMD starts returning error. In (2b) execution will be same, and if PMD already doesn't support NOT dropping, functionality will be same, only configuration will reflect what is actually happening instead of what user thinks happening. > >> >> This is for queue specific offloads, you are returning port offloads. >> As far as I can see bnxt doesn't have any queue specific offload, so this can be >> dropped. > > It wasn't clear to me whether this was intended to report the difference between > the offload configuration for the queue and the offload configuration > for the port > or the effective offload configuration for the queue. I noticed that > several other > PMDs (e.g. mlx5, netvsc, sfc) report the offload configuration for the port in > rx/tx_queue_info_get(). The sfc PMD reports the offload configuration for the > port combined with queue-specific offloads, based on those examples this > seemed to be correct. I guess you're saying those are also incorrect? > May bad, they look OK, "the effective offload configuration for the queue" makes more sense here. I guess I confused same fields should hold the queue specific offloads when used for 'rte_eth_rx_queue_setup()'