From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 83D082BCD for ; Tue, 24 Apr 2018 18:18:13 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 09:18:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,323,1520924400"; d="scan'208";a="53283025" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.42]) ([10.237.221.42]) by orsmga002.jf.intel.com with ESMTP; 24 Apr 2018 09:18:06 -0700 To: "Ananyev, Konstantin" , Thomas Monjalon , "dev@dpdk.org" Cc: Ajit Khaparde , Jerin Jacob , Shijith Thotton , Santosh Shukla , Rahul Lakkireddy , John Daley , "Lu, Wenzhuo" , "Xing, Beilei" , "Zhang, Qi Z" , "Wu, Jingjing" , 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 , "Legacy, Allain (Wind River)" , "Richardson, Bruce" , Gaetan Rivet , Olivier Matz References: <2759953.P7QpFFSjiU@xps> <2601191342CEEE43887BDE71AB977258AEA520B2@IRSMSX102.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258AEA5344F@IRSMSX102.ger.corp.intel.com> From: Ferruh Yigit 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: <7d0f5464-03a9-00db-307e-08d55b88a903@intel.com> Date: Tue, 24 Apr 2018 17:18:05 +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: <2601191342CEEE43887BDE71AB977258AEA5344F@IRSMSX102.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 16:18:14 -0000 On 4/24/2018 4:20 PM, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Tuesday, April 24, 2018 1:28 PM >> To: Ananyev, Konstantin ; Thomas Monjalon ; dev@dpdk.org >> Cc: Ajit Khaparde ; Jerin Jacob ; Shijith Thotton >> ; Santosh Shukla ; Rahul Lakkireddy >> ; John Daley ; Lu, Wenzhuo ; Xing, Beilei >> ; Zhang, Qi Z ; Wu, Jingjing ; 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 ; Legacy, Allain (Wind River) >> ; Richardson, Bruce ; Gaetan Rivet ; Olivier Matz >> >> Subject: Re: [dpdk-dev] Survey for final decision about per-port offload API >> >> On 4/24/2018 12:08 PM, Ananyev, Konstantin wrote: >>> Hi Ferruh, >>> >>>> >>>> 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" >>>> - Application will be limited in queue_setup() to set only an offload within >>>> "queue offload capability" >>>> >>>> >>>> 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() >>>> >>>> >>>> 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 suggest adding disable support to fist one but not second one. >>> >>> Not sure why to introduce such limitation? >> >> Not supporting second one? >> >> To differentiate disable request for that case is harder. How can we say to >> disable a "queue level offloads" enabled by configure()? >> >> It may be by setting these offloads in queue_setup() as well and when any >> offload is missing in queue_setup() it can be taken as disable request. This >> forces applications to duplicate/set "queue level offloads" enabled by >> configure() in the queue_setup() function by default. >> >> This is an option, but my concern was to this may be harder to manage by >> applications. >> An application will have to remove "port level offload" from port_offloads and >> feed it into each queue_setup(). >> >> Also this is closer to existing API but not same, the difference is >> queue_setup() doesn't get "port level offload" >> >> We can go with this one if there is a requirement for it. >> >> And if we prefer to go with this option, perhaps we can think twice about >> changing exiting API because this will be very close the existing API. Only >> logically it is not correct to force application to set some offloads in >> queue_setup() for the PMD that doesn't support queue offload at all, this can be >> handled in PMD, and saves us of all the trouble of the change. > > I suppose both ways are possible - though if we don't allow user to disable queue-specific > offload on particular queue, we would end up with most users just not specifying > any queue-specific offloads at configure() at all - just to have an ability to disable it in future > for particular queue. Yes, this has been mentioned as a easier option to go previously. > > Konstantin > >