From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id EF2342C12 for ; Wed, 25 Apr 2018 00:00:19 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 635D321B03; Tue, 24 Apr 2018 18:00:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 24 Apr 2018 18:00:19 -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=gjaItoYfUS/gcjpnTeoJsjhL2p mZYeJKV3uiudcA044=; b=bUMzHoT38QP81aas3/73ISoBsF18PECYKz+VFoaQoA VmGO0FGQYx3O3Vp8uhkFG/JOOxO0ghsjGb7yQIIG7pwgMsyZe0J2gv6Vl59BEg0I HfRsEzi98JI01JypE+jM46HjN4EwL+29R0fIO9PoRHOgeBMmUOHY42QeKUP+66tE s= 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=gjaIto YfUS/gcjpnTeoJsjhL2pmZYeJKV3uiudcA044=; b=K5h3aNCnf8X5PKHdDbTV1N TInLBanPatjwTKIW+Adeq+HjMvk8h6/wEpz+ZY0S/67pIHVFmE7J3t45om438ev2 5Vh2xx0c1XS5gpfRfkMEH6ux44Ip4fCFQlbhxudSn0LOlJLgB4o37RoCOt3B7Lb+ //6GqDYyKQO9bR5KKCg3WzOvddya1ERdyR+ds/HudoFzGe4hjEPXKgIidRbsXoea ILjZXd6Sh1lj+sysuRSoXeHacXdlRle4oSx6+c4oHJr6h99tY93AsuN4Z+JzJOhL 1WM+fmmyhKUQymP3Dke7qQjxei7oDL3dZJQ4PP/IQ42EXvBrTC/D75jiUy5a7+Dg == 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 E4DF4E4F05; Tue, 24 Apr 2018 18:00:15 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Ajit Khaparde , Jerin Jacob , Shijith Thotton , Santosh Shukla , Rahul Lakkireddy , John Daley , Wenzhuo Lu , Konstantin Ananyev , Beilei Xing , Qi Zhang , Jingjing Wu , Adrien Mazarguil , Nelio Laranjeiro , Yongseok Koh , Shahaf Shuler , Tomasz Duszynski , Jianbo Liu , Alejandro Lucero , Hemant Agrawal , Shreyansh Jain , Harish Patil , Rasesh Mody , Andrew Rybchenko , Shrikrishna Khare , Maxime Coquelin , Allain Legacy , Bruce Richardson , Gaetan Rivet , Olivier Matz Date: Wed, 25 Apr 2018 00:00:14 +0200 Message-ID: <2216799.LoqiUiJk6K@xps> In-Reply-To: References: <2759953.P7QpFFSjiU@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Survey for final decision about per-port offload 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, 24 Apr 2018 22:00:20 -0000 Hi, First, this is my summary after the survey answers and comments: 1/ allow "forgetting" port offloads in queue offloads setup 2/ update documentation, applications and remove checks in PMDs for 18.05-rc2 3/ an offload enabled at port level, cannot be disabled at queue level 4/ The queue capabilities must be a subset of port capabilities, i.e. every queue capabilities must be reported as port capabilities. But the port capabilities should be reported at queue level only if it can be enabled on queue when it is disabled on port level. 24/04/2018 12:39, Ferruh Yigit: > On 3/30/2018 2:47 PM, Thomas Monjalon wrote: > > There are some discussions about a specific part of the offload API: > > "To enable per-port offload, the offload should be set on both > > device configuration and queue setup." > > > > It means the application must repeat the port offload flags > > in rte_eth_conf.[rt]xmode.offloads and rte_eth_[rt]xconf.offloads, > > when calling respectively rte_eth_dev_configure() and > > rte_eth_[rt]x_queue_setup for each queue. > > > > The PMD must check if there is mismatch, i.e. a port offload not > > repeated in queue setup. > > There is a proposal to do this check at ethdev level: > > http://dpdk.org/ml/archives/dev/2018-March/094023.html > > > > It was also proposed to relax the API and allow "forgetting" port > > offloads in queue offloads: > > http://dpdk.org/ml/archives/dev/2018-March/092978.html > > > > It would mean the offloads applied to a queue result of OR operation: > > rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads > > > > 1/ Do you agree with above API change? > > There is a detail of ability to disabling queue level offloads in queue_setup() > function, I want to discuss here. > > Prolog: > port level offload: An offload only can be applied port level, to all queues. > queue level offload: An offload can be applied into individual queues of the port > > PMD reports port offload capability: port level offload + queue level offload > PMD reports queue offload capability: queue level offload > > > Above suggested change to API: > - Application will be limited in configure() to set only an offload within "port > offload capability" "limited" is not the right word, given port offload capability reports also queue level offload capability. > - Application will be limited in queue_setup() to set only an offload within > "queue offload capability" Yes > This doesn't say much about disabling an offload in queue_setup(), as a rule: > - An "port level offload" can't be disabled in queue_setup() Yes > There are two cases of disable: > 1- Disabling a "queue level offload" enabled queue_setup() previously > 2- Disabling a "queue level offload" enabled in configure() > > If second is not supported, to disable the offload, applications should > stop->re-configure()->re-queue_setup()->start the port. But having this > capability makes the offloading parameters more confusing for applications. I don't understand the last sentence. > I suggest adding disable support to fist one but not second one. Yes, it is the item 3 of the survey. > According this, > application: > - In configure() set offload within "port offload capability" > - In queue_setup() set offload within "queue offload capability". Offloads are > incremental to ones in configure() > > PMDs: > - In configure() verify the offload against "port offload capability" > - In queue_setup() verify the offload against "queue offload capability" At ethdev level, we should filter out the offloads already enabled at port level, before calling the queue setup op. > - In queue_setup() if requested offload is not enabled already, enable it for queue > - In queue_setup() if an offload value cleared in requested offload that is set > in port_offload, return error. No The item 1 of the survey is about allow "forgetting" port offloads. If offload is enabled at port level, and not repeated in queue setup, nothing happen. It stays enabled at port level. > - In queue_setup() if an offload value cleared in requested offload that is not > set in port_offload but set in queue_offload, disable it for that queue. Yes > Samples according initial suggestion + disable support: > > Sample 1: > port level offload: A, B > queue level offload: C, D > port offload capability: A, B, C, D > queue offload capability: C, D > > configure(A,C): Q1:A,C Q2:A,C [queue_setup() can't disable A,C after this] > queue_setup(Q1, B): --> Error [Can't enable port level offload in queue_setup()] > queue_setup(Q1, D): Q1:A,C,D > queue_setup(Q1, ""): Q1:A,C [Disabled D] Yes we can disable a queue offload. > queue_setup(Q2, "C,D"): Q2:A,C,D > queue_setup(Q2, ""): Q2:A,C Yes we cannot disable a port offload. > queue_setup(Q2, A): --> Error [A is port_level offload] No, it is the same as queue_setup(Q2, "C,D"). We can repeat an already enabled port offload in queue setup. > Sample 2: > port level offload: A, B, C > queue level offload: "" > port offload capability: A, B, C > queue offload capability: "" [no way to change offloads in queue level] > > configure(A,C): Q1:A,C Q2:A,C > queue_setup(Q1, B): --> Error > queue_setup(Q1, A): --> Error No, we can repeat an already enabled port offload in queue setup. > queue_setup(Q2, ""): Q2:A,C > queue_setup(Q1, ""): Q1:A,C > > > Sample 3: > port level offload: "" > queue level offload: A, B, C, D > port offload capability: A, B, C, D > queue offload capability: A, B, C, D > > configure(A): Q1:A Q2:A > queue_setup(Q1, A): Q1:A > queue_setup(Q1, ""): Q1:A > queue_setup(Q1, A,B,C,D): Q1:A,B,C,D > queue_setup(Q1, B): Q1:A,B [Disable C,D] Yes > queue_setup(Q2, C): Q2:A,C > queue_setup(Q1, ""): Q1:A [Disable B] > queue_setup(Q2, ""): Q2:A [Disable C] Yes