From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id B36695F2E for ; Wed, 21 Mar 2018 15:41:10 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D636620CA7; Wed, 21 Mar 2018 10:41:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 21 Mar 2018 10:41:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=7JnHPoR9MVY7ySJIFRBMszU003 1xhZcgMLJye+/7Hmc=; b=gjt5G6rlZB+EolxCxWqr6vUm6ZCFBgy9A77kFC2kOh s/ApHGWqn4Gjbhb2WtwVM3ayUjUKcdoB64ESdYZJhn59aYLGWktqeibPTjQnyQqm KCcK1RUAcTtYrfDFwuOg3pM65uPsdOOUPrLWt8m3+WBfIz8DTytT9PV9XLUeOl1O c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7JnHPo R9MVY7ySJIFRBMszU0031xhZcgMLJye+/7Hmc=; b=mAV1TZdeeRqGMGm4jCWeGb CfCRn84eQWpRBtq+7388ulVFITeHbBMoX0wImFqFl4ZnUEfbtvAo8+BVe9QkIQRA OJuAl8U7269XV819BlLOgTSthhxpsPp4D9s/3rGJkdmlS55F38N+bPwZ0jpcJfUy Dn8ghBuyW83px7OvInP9hR7dSvdt4pNAz8PxJkciq0ngn/VS/kAS2K/MlJlvUAgL DYT6q9f0cGM4Rs9LrBhoSfO9edaweDoiYIRt1dNLy56quXqPt/1dKJRwBX7fE8SU pBXNsY2Hy5xnwSMnpfvNW+cb7fmm4b2i7C1MVG0Nj1oH5Lq+lNZ9o2Jph8ANb43A == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9BB017E16E; Wed, 21 Mar 2018 10:41:08 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Shahaf Shuler , dev@dpdk.org, Andrew Rybchenko , John McNamara , Marko Kovacevic , Patil@dpdk.org, Harish , Ivan Malov Date: Wed, 21 Mar 2018 15:40:43 +0100 Message-ID: <5699565.CqXomkVGtb@xps> In-Reply-To: References: <44e451f86e4582815767cf75b4e0f01f5cc60b5f.1507104596.git.shahafs@mellanox.com> <4165486.q6vGXG96hz@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:41:11 -0000 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.