From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 87C485F6C for ; Wed, 21 Mar 2018 15:28:40 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 07:28:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,340,1517904000"; d="scan'208";a="35651125" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.63]) ([10.237.221.63]) by FMSMGA003.fm.intel.com with ESMTP; 21 Mar 2018 07:28:37 -0700 To: Thomas Monjalon , Shahaf Shuler Cc: dev@dpdk.org, Andrew Rybchenko , John McNamara , Marko Kovacevic , Patil@dpdk.org, Harish , Ivan Malov References: <44e451f86e4582815767cf75b4e0f01f5cc60b5f.1507104596.git.shahafs@mellanox.com> <5efda914-7017-9095-2546-ae6e4c627295@solarflare.com> <4a4330be-a8c4-599d-d8a7-3703e5af285c@intel.com> <4165486.q6vGXG96hz@xps> From: Ferruh Yigit Message-ID: Date: Wed, 21 Mar 2018 14:28:37 +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: <4165486.q6vGXG96hz@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] doc: update new ethdev offload API description 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: Wed, 21 Mar 2018 14:28:41 -0000 On 3/21/2018 2:08 PM, Thomas Monjalon wrote: > 21/03/2018 11:54, Ferruh Yigit: >> On 3/21/2018 9:47 AM, Andrew Rybchenko wrote: >>> IMHO, it should be allowed to specify queue offloads on port level. >>> It should simply enable these offloads on all queues. Also it will >>> match dev_info [rt]x_offload_capa which include both port and queue >>> offloads. >>> >>> Yes, we lose possibility to enable on port level, but disable on queue >>> level by suggested changes, but I think it is OK - if you don't need >>> it for all queues, just control separately on queue level. >> >> What I understand was queue offload can only enable more, but it seems it can >> both enable or disable. > > Yes, queue offload should only enable more. > An offload enabled at port level, cannot be disabled at queue level. Agree an offload enabled at port level can't be disabled at queue level, but why not have the ability to disable a queue level offload with another queue setup call. > A port offload can be repeated in queue configuration. > If a port offload is not repeated in queue configuration, there should be > no impact: it is still in the port configuration, thus applying to all queues. This was a requirement, this patch targets removing the requirement to repeat the port offload in queue config. > > About capabilities, the queue offloads must be a subset of port offloads. > The queue capabilities show which offloads can be enabled per queue. > >