From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <bruce.richardson@intel.com> Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 444E94C8F for <dev@dpdk.org>; Wed, 21 Mar 2018 16:26:44 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 08:26:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,340,1517904000"; d="scan'208";a="29996020" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.52]) by fmsmga002.fm.intel.com with SMTP; 21 Mar 2018 08:26:39 -0700 Received: by (sSMTP sendmail emulation); Wed, 21 Mar 2018 15:26:38 +0000 Date: Wed, 21 Mar 2018 15:26:38 +0000 From: Bruce Richardson <bruce.richardson@intel.com> To: Thomas Monjalon <thomas@monjalon.net> Cc: Ferruh Yigit <ferruh.yigit@intel.com>, Shahaf Shuler <shahafs@mellanox.com>, dev@dpdk.org, Andrew Rybchenko <arybchenko@solarflare.com>, John McNamara <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com>, Patil@dpdk.org, Harish <harish.patil@cavium.com>, Ivan Malov <Ivan.Malov@oktetlabs.ru> Message-ID: <20180321152638.GA11100@bricha3-MOBL.ger.corp.intel.com> References: <44e451f86e4582815767cf75b4e0f01f5cc60b5f.1507104596.git.shahafs@mellanox.com> <4165486.q6vGXG96hz@xps> <ce11cc17-38b8-97e7-39bf-866bc64737f5@intel.com> <5699565.CqXomkVGtb@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5699565.CqXomkVGtb@xps> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) 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 <dev.dpdk.org> List-Unsubscribe: <https://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 21 Mar 2018 15:26:44 -0000 On Wed, Mar 21, 2018 at 03:40:43PM +0100, Thomas Monjalon wrote: > 21/03/2018 15:28, Ferruh Yigit: > > 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. > > Yes it should be possible to disable a queue offload: > 1/ enable offload in queue configuration > 2/ later disable this offload in queue configuration > > So, when I say "only enable more", I mean queue config should only enable > more than port config. In other words, a port-level offload cannot be > disabled at queue level. > > > > 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. > > Understood, and I agree with this change if it is well explained > in sphinx and doxygen. > It is important to say that queue configuration has no impact on offloads > already enabled at port level. > > > > About capabilities, the queue offloads must be a subset of port offloads. > > > The queue capabilities show which offloads can be enabled per queue. > > > Why not abandon port-level config entirely? Then you just have queue-level configs, with the restriction that on some NICs all queues must be configured the same way. It can be up to the NIC drivers - or possibly ethdev layer - to identify and report an error in such cases. /Bruce