From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 46E2D1B3E3 for ; Tue, 3 Oct 2017 21:46:22 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2017 12:46:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,475,1500966000"; d="scan'208";a="906349324" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.241.224.245]) ([10.241.224.245]) by FMSMGA003.fm.intel.com with ESMTP; 03 Oct 2017 12:46:21 -0700 To: Shahaf Shuler , Thomas Monjalon Cc: "arybchenko@solarflare.com" , "konstantin.ananyev@intel.com" , "jerin.jacob@caviumnetworks.com" , "dev@dpdk.org" References: <217b14a0-8416-619f-a4f2-104fcd1f87ad@intel.com> From: Ferruh Yigit Message-ID: Date: Tue, 3 Oct 2017 20:46:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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 1/3] ethdev: introduce Rx queue 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: Tue, 03 Oct 2017 19:46:23 -0000 On 10/3/2017 7:25 AM, Shahaf Shuler wrote: > Hi Ferruh, > > Tuesday, October 3, 2017 3:32 AM, Ferruh Yigit: >> On 9/28/2017 7:54 PM, Shahaf Shuler wrote: >>> Introduce a new API to configure Rx offloads. >>> >>> In the new API, offloads are divided into per-port and per-queue >>> offloads. The PMD reports capability for each of them. >>> Offloads are enabled using the existing DEV_RX_OFFLOAD_* flags. >>> To enable per-port offload, the offload should be set on both device >>> configuration and queue configuration. To enable per-queue offload, >>> the offloads can be set only on queue configuration. >>> >>> Applications should set the ignore_offload_bitfield bit on rxmode >>> structure in order to move to the new API. >>> >>> The old Rx offloads API is kept for the meanwhile, in order to enable >>> a smooth transition for PMDs and application to the new API. >>> >>> Signed-off-by: Shahaf Shuler >> >> <...> >> >>> @@ -1102,8 +1193,18 @@ rte_eth_rx_queue_setup(uint8_t port_id, >> uint16_t rx_queue_id, >>> if (rx_conf == NULL) >>> rx_conf = &dev_info.default_rxconf; >>> >>> + local_conf = *rx_conf; >>> + if (dev->data->dev_conf.rxmode.ignore_offload_bitfield == 0) { >>> + /** >>> + * Reflect port offloads to queue offloads in order for >>> + * offloads to not be discarded. >>> + */ >>> + rte_eth_convert_rx_offload_bitfield(&dev->data- >>> dev_conf.rxmode, >>> + &local_conf.offloads); >>> + } >> >> If an application switches to the new method, it will set "offloads" and if >> underlying PMD doesn't support the new method it will just do nothing with >> "offloads" variable but problem is application won't know PMD just ignored >> them, it may think per queue offloads set. >> >> Does it make sense to notify application that PMD doesn't understand that >> new "offloads" flag? > > I don't think it is needed. In the new API the per-queue Rx offloads caps are reported using a new rx_queue_offload_capa field. Old PMD will not set it, therefore application which use the new API will see that the underlying PMD is supporting only per-port Rx offloads. > This should be enough for it to understand that the per-queue offloads won't be set. OK, makes sense, so application should check queue bases offload capabilities PMD returned and decide port based or queue based offloads to use. > >> >>> + >>> ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, >> nb_rx_desc, >>> - socket_id, rx_conf, mp); >>> + socket_id, &local_conf, mp); >>> if (!ret) { >>> if (!dev->data->min_rx_buf_size || >>> dev->data->min_rx_buf_size > mbp_buf_size) >> <...>