From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ferruh.yigit@intel.com> Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 1AECA69F7 for <dev@dpdk.org>; Wed, 25 Apr 2018 15:33:04 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2018 06:33:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,326,1520924400"; d="scan'208";a="223290293" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.42]) ([10.237.221.42]) by fmsmga006.fm.intel.com with ESMTP; 25 Apr 2018 06:32:56 -0700 To: Thomas Monjalon <thomas@monjalon.net> Cc: dev@dpdk.org, Ajit Khaparde <ajit.khaparde@broadcom.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com>, Shijith Thotton <shijith.thotton@cavium.com>, Santosh Shukla <santosh.shukla@caviumnetworks.com>, Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>, John Daley <johndale@cisco.com>, Wenzhuo Lu <wenzhuo.lu@intel.com>, Konstantin Ananyev <konstantin.ananyev@intel.com>, Beilei Xing <beilei.xing@intel.com>, Qi Zhang <qi.z.zhang@intel.com>, Jingjing Wu <jingjing.wu@intel.com>, Adrien Mazarguil <adrien.mazarguil@6wind.com>, Nelio Laranjeiro <nelio.laranjeiro@6wind.com>, Yongseok Koh <yskoh@mellanox.com>, Shahaf Shuler <shahafs@mellanox.com>, Tomasz Duszynski <tdu@semihalf.com>, Jianbo Liu <jianbo.liu@arm.com>, Alejandro Lucero <alejandro.lucero@netronome.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Shreyansh Jain <shreyansh.jain@nxp.com>, Harish Patil <harish.patil@cavium.com>, Rasesh Mody <rasesh.mody@cavium.com>, Andrew Rybchenko <arybchenko@solarflare.com>, Shrikrishna Khare <skhare@vmware.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Allain Legacy <allain.legacy@windriver.com>, Bruce Richardson <bruce.richardson@intel.com>, Gaetan Rivet <gaetan.rivet@6wind.com>, Olivier Matz <olivier.matz@6wind.com> References: <2759953.P7QpFFSjiU@xps> <ea9ff099-75a0-e10a-191e-ba8696996a25@intel.com> <2216799.LoqiUiJk6K@xps> From: Ferruh Yigit <ferruh.yigit@intel.com> Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= xsFNBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABzSVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+wsF+BBMBAgAoAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAUCWZR3VQUJB33WBQAKCRD5M+tD3xNhH6DWEACVhEb8q1epPwZrUDoxzu7E TS1b8tmabOmnjXZRs6+EXgUVHkp2xxkCfDmL3pa5bC0G/74aJnWjNsdvE05V1cb4YK4kRQ62 FwDQ+hlrFrwFB3PtDZk1tpkzCRHvJgnIil+0MuEh32Y57ig6hy8yO8ql7Lohyrnpfk/nNpm4 jQGEF5qEeHcEFe1AZQlPHN/STno8NZSz2nl0b2cw+cujN1krmvB52Ah/2KugQ6pprVyrGrzB c34ZQO9OsmSjJlETCZk6EZzuhfe16iqBFbOSadi9sPcJRwaUQBid+xdFWl7GQ8qC3zNPibSF HmU43yBZUqJDZlhIcl6/cFpOSjv2sDWdtjEXTDn5y/0FsuY0mFE78ItC4kCTIVk17VZoywcd fmbbnwOSWzDq7hiUYuQGkIudJw5k/A1CMsyLkoUEGN3sLfsw6KASgS4XrrmPO4UVr3mH5bP1 yC7i1OVNpzvOxtahmzm481ID8sk72GC2RktTOHb0cX+qdoiMMfYgo3wRRDYCBt6YoGYUxF1p msjocXyqToKhhnFbXLaZlVfnQ9i2i8jsj9SKig+ewC2p3lkPj6ncye9q95bzhmUeJO6sFhJg Hiz6syOMg8yCcq60j07airybAuHIDNFWk0gaWAmtHZxLObZx2PVn2nv9kLYGohFekw0AOsIW ta++5m48dnCoAc7BTQRX1ky+ARAApzQNvXvE2q1LAS+Z+ni2R13Bb1cDS1ZYq1jgpR13+OKN ipzd8MPngRJilXxBaPTErhgzR0vGcNTYhjGMSyFIHVOoBq1VbP1a0Fi/NqWzJOowo/fDfgVy K4vuitc/gCJs+2se4hdZA4EQJxVlNM51lgYDNpjPGIA43MX15OLAip73+ho6NPBMuc5qse3X pAClNhBKfENRCWN428pi3WVkT+ABRTE0taxjJNP7bb+9TQYNRqGwnGzX5/XISv44asWIQCaq vOkXSUJLd//cdVNTqtL1wreCVVR5pMXj7VIrlk07fmmJVALCmGbFr53BMb8O+8dgK2A5mitM n44d+8KdJWOwziRxcaMk/LclmZS3Iv1TERtiWt98Y9AjeAtcgYPkA3ld0BcUKONogP8pHVz1 Ed3s5rDQ91yr1S0wuAzW91fxGUO4wY+uPmxCtFVuBgd9VT9NAKTUL0qHM7CDgCnZPe0TW6Zj 8OqtdCCyAfvU9cW5xWM7Icxhde6AtPxhDSBwE8fL2ZmrDmaA4jmUKXp3i4JxRPSX84S08b+s DWXHPxy10UFU5A7EK/BEbZAKBwn9ROfm+WK+6X5xOGLoRE++OqNuUudxC1GDyLOPaqCbBCS9 +P6HsTHzxsjyJa27n4jcrcuY3P9TEcFJYSZSeSDh8mVGvugi0exnSJrrBZDyVCcAEQEAAcLB ZQQYAQIADwIbDAUCWZR1ZwUJA59cIQAKCRD5M+tD3xNhH5b+D/9XG44Ci6STdcA5RO/ur05J EE3Ux1DCHZ5V7vNAtX/8Wg4l4GZfweauXwuJ1w7Sp7fklwcNC6wsceI+EmNjGMqfIaukGetG +jBGqsQ7moOZodfXUoCK98gblKgt/BPYMVidzlGC8Q/+lZg1+o29sPnwImW+MXt/Z5az/Z17 Qc265g+p5cqJHzq6bpQdnF7Fu6btKU/kv6wJghENvgMXBuyThqsyFReJWFh2wfaKyuix3Zyj ccq7/blkhzIKmtFWgDcgaSc2UAuJU+x9nuYjihW6WobpKP/nlUDu3BIsbIq09UEke+uE/QK+ FJ8PTJkAsXOf1Bc2C0XbW4Y2hf103+YY6L8weUCBsWC5VH5VtVmeuh26ENURclwfeXhWQ9Og 77yzpTXWr5g1Z0oLpYpWPv745J4bE7pv+dzxOrFdM1xNkzY2pvXph/A8OjxZNQklDkHQ7PIB Lki5L2F4XkEOddUUQchJwzMqTPsggPDmGjgLZrqgO+s4ECZK5+nLD3HEpAbPa3JLDaScy+90 Nu1lAqPUHSnP3vYZVw85ZYm6UCxHE4VLMnnJsN09ZhsOSVR+GyP5Nyw9rT1V3lcsuH7M5Naa 2Xobn9m7l9bRCD/Ji8kG15eV1WTxx1HXVQGjdUYDI7UwegBNbwMLh17XDy+3sn/6SgcqtECA Q6pZKA2mTQxEKMLBZQQYAQIADwIbDAUCWZR3hQUJA59eRwAKCRD5M+tD3xNhH4a/D/4jLAZu UhvU1swWcNEVVCELZ0D3LOV14XcY2MXa3QOpeZ9Bgq7YYJ4S5YXK+SBQS0FkRZdjGNvlGZoG ZdpU+NsQmQFhqHGwX0IT9MeTFM8uvKgxNKGwMVcV9g0IOqwBhGHne+BFboRA9362fgGW5AYQ zT0mzzRKEoOh4r3AQvbM6kLISxo0k1ujdYiI5nj/5WoKDqxTwwfuN1uDUHsWo3tzenRmpMyU NyW3Dc+1ajvXLyo09sRRq7BnM99Rix1EGL8Qhwy+j0YAv+FuspWxUX9FxXYho5PvGLHLsHfK FYQ7x/RRbpMjkJWVfIe/xVnfvn4kz+MTA5yhvsuNi678fLwY9hBP0y4lO8Ob2IhEPdfnTuIs tFVxXuelJ9xAe5TyqP0f+fQjf1ixsBZkqOohsBXDfje0iaUpYa/OQ/BBeej0dUdg2JEu4jAC x41HpVCnP9ipLpD0fYz1d/dX0F/VY2ovW6Eba/y/ngOSAR6C+u881m7oH2l0G47MTwkaQCBA bLGXPj4TCdX3lftqt4bcBPBJ+rFAnJmRHtUuyyaewBnZ81ZU2YAptqFM1kTh+aSvMvGhfVsQ qZL2rk2OPN1hg+KXhErlbTZ6oPtLCFhSHQmuxQ4oc4U147wBTUuOdwNjtnNatUhRCp8POc+3 XphVR5G70mnca1E2vzC77z+XSlTyRA== Message-ID: <38ef5fed-d664-2c99-543d-89b04f03be0a@intel.com> Date: Wed, 25 Apr 2018 14:32:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2216799.LoqiUiJk6K@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 <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, 25 Apr 2018 13:33:05 -0000 On 4/24/2018 11:00 PM, Thomas Monjalon wrote: > 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. Yes indeed. > >> 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. Above two steps can be moved to ethdev layer, agreed. But I guess you are talking about something else, can you please detail? > >> - 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. Right. > >> - 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 OK, good to agree on this, this was the main topic of this email. > > >> 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. You are right, no need to return error here, since it is already enabled for queue. > > >> 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. Right. > >> 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 > > >