From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0068.outbound.protection.outlook.com [104.47.2.68]) by dpdk.org (Postfix) with ESMTP id 783DD5F2C for ; Fri, 16 Mar 2018 14:54:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jc8HIgditMArjSSkzBtP8ORfs/2vIlyx5hpCN7mipNc=; b=iQlNI160aK9ql3MxvlffJEgJigTrxXqIpVkNh5sev8cnYaqK4drtyJ3jfrXfkUt/BJu1/GQeiGbm3nBZzaharNGWC3nCyVlP7vETBscCWe02ctb77xz5Uq+A5nhBEqq1KBXdOHrPaH+QGmAlGZ8LKns4fjRWfZJmNFx6yomwsGQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; Received: from mail-wm0-f49.google.com (74.125.82.49) by HE1PR0402MB2779.eurprd04.prod.outlook.com (2603:10a6:3:d4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Fri, 16 Mar 2018 13:54:49 +0000 Received: by mail-wm0-f49.google.com with SMTP id 139so3217336wmn.2 for ; Fri, 16 Mar 2018 06:54:49 -0700 (PDT) X-Gm-Message-State: AElRT7Gg1v8HfVHv7mAt+zbHT1T8X96OooJLCKCstk4QW8brg0UPcUm3 11GU3c47A+fxqVff9ae6hjFMk6bnvcOBgNLQI3g= X-Google-Smtp-Source: AG47ELvNWsaaDtgpk2+fvZQqn6NRB2WZJCj9lbJle/Qu9WlwQRIutTWk+L4oGZWdB9ugbnpwgh3UaSpffaWQ9p04qm0= X-Received: by 10.28.208.70 with SMTP id h67mr1982639wmg.95.1521208484686; Fri, 16 Mar 2018 06:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.135.130 with HTTP; Fri, 16 Mar 2018 06:54:14 -0700 (PDT) In-Reply-To: <97dc9f9d-041b-ef99-2ca6-1f557c4f6039@intel.com> References: <20180307120851.5822-2-remy.horton@intel.com> <023fbd6c-7cac-6c8b-9a40-7a62e5d47bb7@intel.com> <30b8575d-4aeb-912d-6f74-c49ad7ce879a@intel.com> <591e1a23-8d27-0c59-fd39-0bde9e48e96f@intel.com> <2601191342CEEE43887BDE71AB9772589E28FD57@irsmsx105.ger.corp.intel.com> <2b3a2579-6bce-55f5-6e03-0974729cc95b@intel.com> <20180314213658.GA108@bricha3-MOBL.ger.corp.intel.com> <20180315143924.GA9172@bricha3-MOBL.ger.corp.intel.com> <97dc9f9d-041b-ef99-2ca6-1f557c4f6039@intel.com> From: Shreyansh Jain Date: Fri, 16 Mar 2018 19:24:14 +0530 X-Gmail-Original-Message-ID: Message-ID: To: Ferruh Yigit Cc: Bruce Richardson , "Horton, Remy" , "Ananyev, Konstantin" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Wu, Jingjing" , "Zhang, Qi Z" , "Xing, Beilei" , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [74.125.82.49] X-ClientProxiedBy: VI1PR0802CA0028.eurprd08.prod.outlook.com (2603:10a6:800:a9::14) To HE1PR0402MB2779.eurprd04.prod.outlook.com (2603:10a6:3:d4::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1b9ce554-e369-4c8b-2c13-08d58b457c0f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0402MB2779; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0402MB2779; 3:rNDNJwh3W/ymnR+0TL6A/gLsckO8FfhHvWJ8r6UKyDdTNB68R4LISpCBggcIMGNmnH8+HcitKDXLBpAk3tY/+M2E/lQ06uX6nGNv0phd5zWSyOBATlZl5/Bb2AxKQj46yPFUQckRTENPe5nxvp1ngTPAH9qHfadrwwX90O3JPiTU1DDxmex4HqOA4X8ezdnAsewWJ2N2c2cKr4IAI8fbjVNvf66rS2eukBwJcWHiBSNrJMPah9KrVrXW1q6pF5d4; 25:W6tRLR0QXMeEkbI/6Ut2m4imTvE+I2JL5Hrj9ERwy9ZV1h+ViIBYLys3rLdySsTviGgXuCbrtiCLIGpdvYT0jgI8NdHKQB9SwcTSsv3GR8/+YOw9rUQeHq5kOpQlOKUaYpxfgY2bYFjjrhvPM7wx4Pd+ZDObUJuO4d8UIO7u9eGDMjhCVb6VpVAFyUakJk9+HXWQb4F2RA/0ggbWEeNUuBUb2xq3LNGLFQ4F6Q/KIvbJgvCrIYD6T5mrcUGh+hOR5oUF1oHvngaWOIxGaKmIbg7UbAHqiWeJUK8PlawLCBs8MlIkfbB+ySLE25KNWTedoA/l0ULTeSmM5C3Hc6eoAQ==; 31:DBLC9ygECdlQR78iqvX/lOuhbN7hx9Krgqow1Zcu4Un4E8g/MqeOq28tjmMpAOAFynY8YpwQtUHNu1V247mJYF72YY29gd9lBO0eS5RBd98gIp8W6aqDjyDgcbWTOT7dw3k5kOD+oO8xqIwzA14yqno8kI8Y/UxkBv1dXsiutZeQJMR5mindAL5PrITG73YJ7/fM2GZHAngkxelFtqTll6wbRZl4zQKjLnZFdx+7i4I= X-MS-TrafficTypeDiagnostic: HE1PR0402MB2779: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0402MB2779; 20:HqsIrfy5nr5fviZ62IWEA/hdF23HBI9GgJw7Lgt9mc9IQK0P6Q/AeOcWSNS0irwqmEL9Apr6l3QkW0tyUoyYTG0PuQ/cm4AXgP+lA01F2MUhFSnNU1UCFNtsDbHd9k9lhSoMMGIXxJ3lS6Gj3cOutzMbx9X63azF+zAi46j0PRzbirQQ9lubNTFh674yRVaQRT+zFdJxfZyA0tHxVGA1BUXa98iECE83LoFiM5Hyx3Q0k+MLa30nEXFvGDZA7DtzLYDIWnpR+8iBcdoNR5SswZsufkoVSdKDaoWovAcLhAWhk0v8d56V5OLkQwVXYVJcy4yKhf1cgBqGsYC+GeMwS4sb13HP68tO2luqxOJXeK/sk0yNblNRCJx1vuxX1B5p1lVou6g6wovh2si02ZTZl3V1wy8kUEXgp+v3Y8bf7eut822psZHjlyMyFV8maRttvhOAehZD2iVvnn5DRKK2nHLQ8EZyJW8xNMuZWR6Jj/IbTxQCgcL7VOsMHTyWkcLF; 4:adoHzoMpFpfQUUeGHehEvUWS0GJt+18CexmBL49rjBidRXV/kIX4YZD1Rh9ixzerpvjZTpxVy4ZRUQBu2e3M5CU5s3tXDALkt2+sfMjAT4IzXdDA8GHdjcmI/5y7/k4rK5aNEL2fZZxfeizVM4jyMc2CXQTT2gyifc8RO7Ou47BsD9RRcvv6PmKAEoOaVdqzcyWTXSvw8wJi7ZxqoiGNzilTaJflVMYibhudAzLVgrrYSOazy1O/7aAWKrMKEmFcYYUPHCfJNYv5p/8Cr3O5wjXEIe7WT80lzJ22yOWR6hRh9Zrj4x5DM/BQo8bb/mRvdDIerDz1KO/ZfcPR5MShDIEOeG4yoowBGzgy/0nrwr0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231221)(944501244)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0402MB2779; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0402MB2779; X-Forefront-PRVS: 0613912E23 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39380400002)(366004)(396003)(39860400002)(199004)(189003)(76104003)(13464003)(93886005)(561944003)(4326008)(122856001)(6862004)(95326003)(7736002)(6116002)(52116002)(3846002)(23676004)(86362001)(55446002)(93516011)(76176011)(2906002)(5820100001)(305945005)(478600001)(105586002)(54906003)(33896004)(47776003)(5660300001)(61266001)(498394004)(8746002)(186003)(386003)(8936002)(97736004)(107886003)(69596002)(316002)(42186006)(26005)(9686003)(81166006)(81156014)(229853002)(6246003)(66066001)(55236004)(53936002)(8676002)(59450400001)(50466002)(106356001)(68736007)(53546011)(61726006)(9896002)(2950100002)(217873001)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0402MB2779; H:mail-wm0-f49.google.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA0MDJNQjI3Nzk7MjM6NmVhYW9waG9VV3hLTHZWemdIaFRncTFm?= =?utf-8?B?eTZHVS9lVUd6N2JObDRUQmlaNGY2YThyVVBKaFdIL3NyQjllY2o3dmRnb3I5?= =?utf-8?B?VjhqWWFMcWNNMXREczNhTDBvS1FLYnVZbHp6SExRMnNvT0k5QVJKaldBMGZN?= =?utf-8?B?VW9CQWlpYzlxaGFBSDU2UTJla2RqMDMwcWw3SksvQzk2cndmOHh1dHVFZ0hP?= =?utf-8?B?cGwzOE5MZ0lvQ0kwemZQei9WeUVrRXlUalBhNG5mK1FTbk5CV0p2QXZrTnNq?= =?utf-8?B?V1RjcVpBRVRxdUhLczQ3WnR1cHkya1JOTDRPcHJoOGxOeWZNSVVTeHFxeUdu?= =?utf-8?B?MHJrTE5xUE95cWdPQXFpdEcvNlk2MzlkL1Vleno2RUZlWmdDenR2S3FZaXM2?= =?utf-8?B?TThBTG5sam85eVgxWmgxbUY5bmtxRTIxNWhRcUl2bnFOUUhETDFsSHFkT281?= =?utf-8?B?d0Rhc290emtKY0g3VWpQQnM1MDBDRzkvTHpHQWxUaU5wYUFZK0Z6Zy9UaEYy?= =?utf-8?B?Ni80aVkvblNjNWVkQnNHWkFoL0QvenpzMUdwanlIQmMxRkVxUXVmUnBTYmJh?= =?utf-8?B?aHJGRDBOdjk1eUZXV3pFNzh2K2hITTZvbW9YckJDS2c4S21xSXVCMllKbmk4?= =?utf-8?B?MnBNaUsyV1ZVOWdrRGcwcHVxR2JhWU1lSThMSStPU3VRVjlmZnY1YUpHM1Nr?= =?utf-8?B?Q3RlNnMyV2V1OVYwQmZmVFBXSk0wRWFCUVNLSSs2blZaLzFhTFdkK2s0aDBw?= =?utf-8?B?andRSVFaaVpOaTFFMDdHbS96ZUhrR3VLRHdDYXVOdVNqWm5nZ3JQenhseDNz?= =?utf-8?B?bU50dG1wZnBzTGdHVWdQV0NJbE5FTVN4a3cyYkU4clc5VjVUbzFYNStjTzB6?= =?utf-8?B?MitadkRtTVVTMUR0TFZENmNFNGhBeitvTENiZGtZM1poMHhCN25mQUpqa29M?= =?utf-8?B?S3hrSGovUmNoZ0sxdUpKSmNMQXA3V2hmYTFPSnN4L21zL3RmUDJPUXZhcUFi?= =?utf-8?B?RHBHWWJDMm9Dc0c2YVBpdkhyOVNWRDdIZHNKYUR3STcvNlg4NWdGVktwU1RE?= =?utf-8?B?OVZOQUtPT3Q4cHhjMnluQklkRExmWlBIU3BWY00vSTJyeXRqVndIWk1ZSmtE?= =?utf-8?B?NFVvWDJNS2I4ME5CTVdEZTVzMC9rZWRyVENhOTd3N291R2Z6YWpHdTFjWnJH?= =?utf-8?B?OVZwYXM5LzJtcVFNdDZoSW5IYjFXQVlFVHlZSHdYSC9RclZFUFhQdjNQMmx0?= =?utf-8?B?SzljMzBiWUJWaWNreit0RVE5WDRxclZLbmFzaGpFdzI2QXRTdkJBV0NxZnVX?= =?utf-8?B?M3hWcU1JcHM2V08zY2pTaS9BekI1WkppczM4cWN0RWxBaXJaTjFLYlphUnlF?= =?utf-8?B?SlhPelhqNE5OYnA0QzBPZVMvUmh1RzRhOUV5YVB3b3B5R0JaN0dPZCtwZUdU?= =?utf-8?B?bFRSNTJHRU04YnVIWEoraUdPWWtXeEdnTW5JNk9qN3dmRzA3YXQrV01DZkk4?= =?utf-8?B?SUtValpKSHRQTWNFU1RMRkhldU50ZGpvdUlkYVpNZTJLcFFRTVBZUTZXSy9T?= =?utf-8?B?b1g3amIwbWNLYytBV0hHVTBMVkcxdDZMUXdQelF6WXlML3Y4a1YwWEh1Q2N0?= =?utf-8?B?YzVoRFlJbTRSSUJGc0ppOUgvdFc2aXVyNnhqQytJc0krOERQMU1iRUQ3bExZ?= =?utf-8?B?aFV4ZWQ0Y0c1Zi9CUmdvYnFFTVEvUEFOWCtxZjJpSmlwQUY2Q1B1QnhvRjZD?= =?utf-8?B?YnJRam8xN2p3ZWw3amRObFhobEMvZkI5RFdybnpLNUUzZzhJclpQVkFib0VR?= =?utf-8?B?SlB2VGdpK0YwQlpuZThwRy94WGIvWlIrQU9mQWtGS3NMNDg3Ukxtck8zWksw?= =?utf-8?B?RWgrWXI3QVdha3FGcnM2QlUwRXRtQk83cmNOL294ekVqTWVNREFyb2g0MExO?= =?utf-8?B?ME9hM3VwRUxjUnZKRGxNdlNLSW9xeFVMQ0d3NUJoWHNRQjZnR1MxbFFnalNS?= =?utf-8?B?WC9CZ2dGb2hneXk2RGRUL2JiNlRoZVhXdWk3N0RRPT0=?= X-Microsoft-Antispam-Message-Info: amAH1h3+ttTvm2P1oFhP99AqqXzArzjN0jhZRdDWMQoYjwb+wj158S3Pw5nNV04zd2qSUa5FpeBrASpciYHaZrwjlILFJMvCalqlmZYqAnuLhrqTlOnptqH77BOaUY3JFhXeGEPUcGGSdyQm9ljUiTMpGgpf++I5tJ03FwNYETjvnDqjtDBFwKLbEvIm/jGK X-Microsoft-Exchange-Diagnostics: 1; HE1PR0402MB2779; 6:1Ac0JG5V3JUu3v1qLvQi6rfNs4kaWyZbWRGCcxSMRT7e2tSnpJGtv6RN9QbwGnHDVVl4tx66z/ELExSOUL6FAaOnGO7c6IXvsopyGD7OVj5QZnuMW9ZZHfWwhmf2cxyxtRA77Ehe+etwQdCOwnr0cVwBvvzoe/0ECki9UeFvWWsL6iII3Zxioz2wSU+CV6/XZOQXqMry67csRRAdOG01WIphsdRZciuf0NDXhscT9fNjfy/cc0NJmXahssvfRBXSHfGpejejrWVD4JENah43Ma0saIbmHfOXUp/s58wdiWbntLTsvCUPCimR/O74IcIV+ZzISGDvhf7xCkTc8R2EZ93LGo2hDwbVwhoGZSqA13g=; 5:gejYgd1CwBnonriLThr03KLmwg1fkchLm0uZSA/6dReh7U3qgCvH7m0tGWykrvcgrOoLzr11RvMewP77pBC1U1VhaihTKmyTUdnwRTSP1DRQweXblvzLjCpjkUZ6RL1b6+DWX/pBYDEfYJagtaaO5LrjAAlqzjLhN/oqdDUynoo=; 24:qCfXhcVXVZOxa+xNhxAFDUKrdxyoKG1ZQEMplzXtZr0s430oxq6ML/wFgMDveCz28U9nACRNvuC5FaUoKpH3VGMfzyEV84fHvOKqWZnA35w=; 7:6r/eWpCS2OPSc/T2fbsatxOaps9vDXfkBAxSGlxfTrypEen6pg8ssnWgBTbLT+VX8AikzVi62THlMNi9wkq2DscOtyIV5IU2aJpCLkF3cGF2IAFrlsb2Z/4hmvO6Nw2GCrCmox0rQT96XVgGH0GA+ZpTwBLy2xHYOc+8caXG1gQFl0ftLmUH7eNl5vdSYemx2ULqIISz/5dONNhSkFT24zkUJ2vMb2nnXer1JGyHSC2HDLJlkdWIP0HdQmTi1EUW SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2018 13:54:49.3166 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1b9ce554-e369-4c8b-2c13-08d58b457c0f X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0402MB2779 Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters 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: Fri, 16 Mar 2018 13:54:51 -0000 On Thu, Mar 15, 2018 at 8:27 PM, Ferruh Yigit wrot= e: > On 3/15/2018 2:39 PM, Bruce Richardson wrote: >> On Thu, Mar 15, 2018 at 01:57:13PM +0000, Ferruh Yigit wrote: >>> On 3/14/2018 9:36 PM, Bruce Richardson wrote: >>>> On Wed, Mar 14, 2018 at 09:02:47PM +0000, Ferruh Yigit wrote: >>>>> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit >>>>>>> Sent: Wednesday, March 14, 2018 5:52 PM >>>>>>> To: Shreyansh Jain ; Horton, Remy ; dev@dpdk.org >>>>>>> Cc: Lu, Wenzhuo ; Wu, Jingjing ; Zhang, Qi Z ; Xing, Beilei >>>>>>> ; Thomas Monjalon >>>>>>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for = PMD-tuned Tx/Rx parameters >>>>>>> >>>>>>> On 3/14/2018 5:23 PM, Shreyansh Jain wrote: >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] >>>>>>>>> Sent: Wednesday, March 14, 2018 10:13 PM >>>>>>>>> To: Remy Horton ; dev@dpdk.org >>>>>>>>> Cc: Wenzhuo Lu ; Jingjing Wu >>>>>>>>> ; Qi Zhang ; Beilei = Xing >>>>>>>>> ; Shreyansh Jain ; >>>>>>>>> Thomas Monjalon >>>>>>>>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support fo= r PMD- >>>>>>>>> tuned Tx/Rx parameters >>>>>>>>> >>>>>>>>> On 3/14/2018 3:48 PM, Remy Horton wrote: >>>>>>>>>> >>>>>>>>>> On 14/03/2018 14:43, Ferruh Yigit wrote: >>>>>>>>>> [..] >>>>>>>>>>>> lib/librte_ether/rte_ethdev.c | 18 ++++++++++++++++++ >>>>>>>>>>>> lib/librte_ether/rte_ethdev.h | 15 +++++++++++++++ >>>>>>>>>>> >>>>>>>>>>> Can you please remove deprecation notice in this patch. >>>>>>>>>> >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>>> + /* Defaults for drivers that don't implement preferred >>>>>>>>>>>> + * queue parameters. >>>>>>>>>> [..] >>>>>>>>>>> Not sure about having these defaults here. It is OK to have def= aults >>>>>>>>> in driver, >>>>>>>>>>> in application or in config file, but I am not sure if putting = them >>>>>>>>> into device >>>>>>>>>>> abstraction layer hides them. >>>>>>>>>>> >>>>>>>>>>> What about not providing any default in ethdev layer, and get z= ero >>>>>>>>> as invalid >>>>>>>>>>> when using them? >>>>>>>>>> >>>>>>>>>> This is something I have been thinking about, and I am going to >>>>>>>>> remove >>>>>>>>>> them for the V2. Original motive was to avoid breaking testpmd f= or >>>>>>>>> PMDs >>>>>>>>>> that don't give defaults (i.e. almost all of them). The alternat= ive >>>>>>>>> is >>>>>>>>>> to put place-holders into all the PMDs themselves, but I am not = sure >>>>>>>>> if >>>>>>>>>> this is appropriate. >>>>>>>>> >>>>>>>>> I think preferred values should be optional, PMD should have righ= t to >>>>>>>>> not >>>>>>>>> provide any. Implementation in 4/4 forces preferred values, eithe= r in >>>>>>>>> all PMDs >>>>>>>>> or in ethdev layer. >>>>>>>>> >>>>>>>>> What about changing approach in application: >>>>>>>>> is preferred value provided [1] ? >>>>>>>>> yes =3D> use it by sending value 0 >>>>>>>>> no =3D> use application provided value, same as now, so control= should >>>>>>>>> be in >>>>>>>>> application. >>>>>>>>> >>>>>>>>> I am aware this breaks the comfort of just providing 0 and PMD va= lues >>>>>>>>> will be >>>>>>>>> used but covers the case there is no PMD values. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> it can be possible to check if preferred value provided by compar= ing 0, >>>>>>>>> but if 0 >>>>>>>>> is a valid value that can be problem. It may not be problem with >>>>>>>>> current >>>>>>>>> variables but it may be when this struct extended, it may be good= to >>>>>>>>> think about >>>>>>>>> alternative here. >>>>>>>> >>>>>>>> I don't think we should use the condition of "yes =3D> use it by s= ending value 0". That is non-intuitive. Ideally, the application should que= ry >>>>>>> and then if query responds with value as '0' (which can be valid fo= r some variables in future), it sends its own value to setup functions >>>>>>> (whether '0' or something else, in case of 0 response, would depend= on the knob). >>>>>>> >>>>>>> Right, at that stage application already knows what is the preferre= d value and >>>>>>> can directly use it. >>>>>>> >>>>>>> >>>>>>> Will it be too much to: >>>>>>> >>>>>>> 1) Adding a new field into "rte_eth_[rt]xconf" to say if exists pre= fer PMD >>>>>>> values. "prefer_device_values" ? >>>>>>> Application can provide values as usual, but if that field is set, = abstraction >>>>>>> layer overwrites the application values with PMD preferred ones. If= there is no >>>>>>> PMD preferred values continue using application ones. >>>>>>> >>>>>>> >>>>>>> 2) Add a bitwise "is_set" field to new "preferred_size" struct, whi= ch may show >>>>>>> status of other fields in the struct, if PMD set a valid value for = them or not, >>>>>>> so won't have to rely on the 0 check. >>>>>> >>>>>> That all seems like too much hassle for such small thing. >>>>> >>>>> Fair enough. >>>>> >>>>>> If we really want to allow PMD not to provide preferred values - >>>>>> then instead of adding rte_eth_dev_pref_info into dev_info we can si= mply >>>>>> introduce a new optional ethdev API call: >>>>>> rte_eth_get_pref_params() or so. >>>>>> If the PMD doesn=E2=80=99t want to provide preferred params to the u= ser it simply >>>>>> wouldn't implement that function. >>>>> >>>>> Same can be done with updated rte_eth_dev_info. >>>>> Only application needs to check and use PMD preferred values, so this= will mean >>>>> dropping "pass 0 to get preferred values" feature in initial set. >>>>> >>>>>> >>>> I actually don't see the issue with having ethdev provide reasonable >>>> default values. If those don't work for a driver, then let the driver >>>> provide it's own values. If the defaults don't work for an app, then l= et >>>> the app override the provided values. >>>> >>>> It really is going to make the app writers job easier if we do things = this >>>> way. The only thing you are missing is the info as to whether it's eth= dev >>>> or the driver that's providing the values, but in the case that it's >>>> ethdev, then the driver by definition "doesn't care", so we can treat = them >>>> as driver provided values. What's the downside? >>> Abstraction layer having hardcoded config options doesn't look right to= me. In >>> long term who will ensure to make those values relevant? >>> >> >> Let me turn that question around - in the long-term how likely are the >> values to change significantly? Also, long-term all PMDs should provide >> their own default values and then we can remove the values in the ethdev >> layer. >> >>> When application provides a value of 0, it won't know if it is using PM= D >>> preferred values or some other defaults, what if application explicitly= wants >>> use PMD preferred values? >> >> If the PMD has preferred values, they will be automatically used. Is the= re >> are case where the app would actually care about it? If the driver doesn= 't >> provide default values, how is the app supposed to know what the correct >> value for that driver is? And if the app *does* know what the best value >> for a driver is - even if the driver itself doesn't, it can easily detec= t >> when a port is using the driver and provide it's own ring setup defaults= . >> If you want, we can provide a flag field to indicate that fields are eth= dev >> defaults not driver defaults or something, but I'm struggling to come up >> with a scenario where it would make a practical difference to an app. >> >>> >>> The new fields are very similar to "default_[rt]xconf" in dev_info. Ind= eed >>> perhaps we should use same naming convention because intention seems sa= me. >>> And we can continue to use new fields same as how "default_[rt]xconf" u= sed. >>> >>> What about having something like rte_eth_tx_queue_setup_relaxed() where >>> application really don't care about values, not sure why, which can get= config >>> values as much as from PMDs and fill the missing ones with the values d= efined in >>> function? >>> >> >> Or how about having the ethdev defaults in the rx/tx setup function inst= ead >> of in the dev_info one? If user specifies a zero size, we use the dev_in= fo >> value if provided by driver, otherwise ethdev default. That allows the >> majority of apps to never worry about ring sizes, but for those that do, >> they can query the driver defaults directly, or if not present set their >> own. > > OK this at least gives a way to application to know where defaults are co= ming from. > > > Hi Remy, Shreyansh, > > What do you think about using a variable name consistent with existing > "default_[rt]xconf" in dev_info? It just turned out to be much more complex than I initially thought :) Is this what the above conversation merging at (for Rx, as example): 1. 'default_rx_size_conf' is added in rte_eth_dev_info (and this includes I/O params like burst size, besides configure time nb_queue, nb_desc etc). Driver would return these values filled in when info_get() is called. 2a. If an application needs the defaults, it would perform info_get() and get the values. then, use the values in configuration APIs (rx_queue_setup for nb_rx_desc, eth_dev_dev_configure for nb_rx_queues). For rx_burst calls, it would use the burst_size fields obtained from info_g= et(). This is good enough for configuration and datapath (rx_burst). OR, another case 2b. Application wants to use default vaules provided by driver without calling info_get. In which case, it would call rx_queue_setup(nb_rx_desc=3D0..) or eth_dev_configure(nb_rx_queue=3D0, nb_tx_queue=3D0). The implementation would query the value from 'default_rx_size_conf' through info_get() and use those values. Though, in this case, rte_eth_rx_burst(burst=3D0) might not work for picking up the default within rte_ethdev.h. :Four observations: A). For burst size (or any other I/O time value added in future), values would have to be explicitly used by application - always. If value reported by info_get() is '0' (see (B) below), application to use its own judgement. No default override by lib_eal. IMO, This is good enough assumption. B). '0' as an indicator for 'no-default-value-available-from-driver' is still an open point. It is good enough for current proposed parameters, but may be a valid numerical value in future. IMO, this can be ignored for now. C) Unlike the original proposal, this would add two separate members to rte_eth_dev_info - one each for Rx and Tx. They both are still expected to be populated through the info_get() implementation but not by lib_eal. IMO, doesn't matter. D) Would there be no non-Rx and non-Tx defaults which need to be shared? I am not sure about this, though. Sorry if I am repeating everything again, but I got lost in the conversation and needed to break it again.