From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B644745EEE; Thu, 19 Dec 2024 18:12:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 88ACB40265; Thu, 19 Dec 2024 18:12:20 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by mails.dpdk.org (Postfix) with ESMTP id 7CF544025F for ; Thu, 19 Dec 2024 18:12:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734628339; x=1766164339; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=nvJHXbZGiGFwmwkKqjIMM4Vzf2G2oTYRtMrYW501zLU=; b=S2oODPRPbnvfHATPFdozwIlmDyc9PNc182WHgm4QS8vjzwMJReXguMpU IIGXk2ch85gTYsHlnpLyrizTlVqadCehchQWynS+LRzbz5rQ8E9FlJlC5 6Qs9FtreJllDm8iVE/cMd1AaV2SeqNMSqwi1SGWrJcdfeVgGekOeZABlX sdQ15kFI1zvuleQUIlvqwgP3OgqJ95fjTmHdWHm2oQbm+FpolWXW0dfiJ lynhX4e9C5oO+Qixmg3qcqWJ/GGaMU7e6i2ACVUUZkAVD1X1Id7Jv7nxB ziMerXEvxfSaQ7Y6KTVwUfZKpBKd/JkGxyiTZujSdrklvYtEtfShZLSdB g==; X-CSE-ConnectionGUID: FwlcR+zNQyC2ScKWOBh46g== X-CSE-MsgGUID: 4F4aV1++Rl+U3JF8K3sKIw== X-IronPort-AV: E=McAfee;i="6700,10204,11291"; a="35317789" X-IronPort-AV: E=Sophos;i="6.12,248,1728975600"; d="scan'208";a="35317789" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Dec 2024 09:12:15 -0800 X-CSE-ConnectionGUID: 2d7WzguzTC+p7TleI/8Ysw== X-CSE-MsgGUID: jnXMNjhvSxKR4cLnB47+5w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="135584600" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orviesa001.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 19 Dec 2024 09:12:14 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Thu, 19 Dec 2024 09:12:13 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44 via Frontend Transport; Thu, 19 Dec 2024 09:12:13 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.48) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Thu, 19 Dec 2024 09:12:12 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=g2dLP2lanHi+mGbomSoi+4O4wdCIn38XpyR2fy3sc175HpJH0Nz8nY7VABBXHiy6x77osjbz9V5ibwB86Vd+cYu7ws89EdJ4qeZw07P9v3Rk2L6IN0aekhnxs487iM9d4JBhBb8htTjHAQQ1WbXU9Age+zXDhgmxMTF/cIgvz7UFtUR/7Jx6L8Wkmige9vr2wolIF1tzENL75r86197AuaX57W5/6Orbw5GpnpGmrOXZDTyYisLFcM4lRtHNLhbhsxKQ/x9t0CDIuQbvW0BimsypDuLdc7bZ50qVkYaQQ3GgEFi6uO21vDjRwKEOjTC3yAWAFREzbBd6qBrQASGDZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7Y55tr3VrDwJrMwIViiQltSMD5urzSfGI/Ap7BdmgNo=; b=IybTXZ2l73z1OSb6hxVLVR/YyVHWzuaCDcKv/4s19ogMi6+x83beFLwwLgHKXgRcGhOqUCVBuoUFYjwA64D3KmDl+EU4FVY5U3bZWpARs2sK5U5VtajiU5NGG05MTYiZsCZhBo8nB8ZpPJAflmKezN9y967TYK7HF7zTysotZsxOY+d2QE1icV1dIHgzegQBHKa1prD4CbSeK4pXzDonxBnFgwAZqnX8uLr4UVmJrq8W1tEoQZW6iHNGol1v+3piR5dGdweAMFI/4f8T6JnR3+sscAkkwI5xP96NSgChl1XOteEsl23jIU1x/O8rCJP/tcsIi6InmqzYTgIt8IV9rQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by IA0PR11MB7752.namprd11.prod.outlook.com (2603:10b6:208:442::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Thu, 19 Dec 2024 17:12:09 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b%4]) with mapi id 15.20.8093.018; Thu, 19 Dec 2024 17:12:09 +0000 Date: Thu, 19 Dec 2024 17:12:02 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Mattias =?iso-8859-1?Q?R=F6nnblom?= , , Jerin Jacob Kollanukkaran , Daniel =?iso-8859-1?Q?=D6stman?= , Naga Harish K S V , , , , Mattias =?iso-8859-1?Q?R=F6nnblom?= Subject: Re: rte_event_eth_tx_adapter_enqueue() short enqueue Message-ID: References: <903aa783-5956-4020-b2a0-48def17fe03f@lysator.liu.se> <24837b70-29fd-472a-aa1d-ab350d6ba5c8@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F96A@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F96A@smartserver.smartshare.dk> X-ClientProxiedBy: MI2P293CA0002.ITAP293.PROD.OUTLOOK.COM (2603:10a6:290:45::17) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|IA0PR11MB7752:EE_ X-MS-Office365-Filtering-Correlation-Id: 6fd8fad3-541b-4e01-eb99-08dd2050453a X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?O3XWNDhez3VFrmHSGxLwxGBAwRSo1tJL35jLT0cYu0u/fnq8ms+JRSR2/w?= =?iso-8859-1?Q?sKm6fJwzZqvfHUW2/xxQ3HlIK8r19N9gUQ1lCI9Nn2NkBMLEKa/4Fu2bqy?= =?iso-8859-1?Q?OgFB5YizQcL3MExfeqiLggTh92+o2P8JLl0EWTueps1iepiPoYo9NFdnuR?= =?iso-8859-1?Q?wBnQAl0E2IoV3ikTUPOf8jC3EQ/pSFKPj8LpNvEX2izduhgg4T4ej7AoD5?= =?iso-8859-1?Q?fkfKj0rb7+6iviOOzxVnpBdkBziwo/h2o1fEGrl8H7SoOIdtjCgnV4fPAp?= =?iso-8859-1?Q?ltL7wnygAg6fcQNqFi6lqoO19Rgt31uBnallJY7lZcG6mIrEiXc3Da0mKZ?= =?iso-8859-1?Q?zdXwPtC2qgYzDTTzGNYRJJgrBfe/9nEw43rH7X3ar2eX6Gl79qqntScsrx?= =?iso-8859-1?Q?mQgQFgbKykAJbKzz05AVue4a53f7bVIa1mSABINPD7YY7ojedhG3qVD+M5?= =?iso-8859-1?Q?kXteE7DbrGbsO/Fo78Pi76iPyJt3k3aiMVS/j0iTwhNTbkZn+7MZSdWXbe?= =?iso-8859-1?Q?VDAHqC1d7U8OhqrUxtz+e7aM6J7pChMmlmi7nmBT0IQH4cfg0GV01mU1C3?= =?iso-8859-1?Q?gzGcNw8hKWTMbpG3FHtvXVU0+fcu3Mr9kmomlfXvslXdt3xNxs/hGbbCim?= =?iso-8859-1?Q?WU7y7+cKAspPfxTfwmTaS9Ow15YdSGlgm/JivqBMACu7sv1xUDW19aXDF0?= =?iso-8859-1?Q?S9Xw8ADHI/q6V8iLs1w8gjdcdlviJ8a/yz8NqH8BH5AZSrwh+TXhKkKNWW?= =?iso-8859-1?Q?7b4mFQzaUld5e4gRn12RxPAtfzDz/Mf1SSMldOWPv0t3ApsOGHpJ1bEr34?= =?iso-8859-1?Q?HKmLRY9GasQR/IRQjCRR5H5ECuNJ+ctgMCQhpyMz0W0pVLJahbxEbSDjOp?= =?iso-8859-1?Q?dhA6Z7OhNGTpsdmg2Y+C9GDH/kzc5MiDySrIQaY8fA29+VL6c0pS+dP8if?= =?iso-8859-1?Q?oc4PBWSdkeHC9sahzVmHRo60Is35lyj4qW0gcLo6/gaPBBLaps4gNAEkQw?= =?iso-8859-1?Q?o/zNvsOupVwClthd/ycxu0O5ddd0nka8s4GzM9zf6XiByjNa/nV0KlcPiT?= =?iso-8859-1?Q?CoNGkU6bJOsduA3HuiCqo8+1D1Ly9QLY0+H3PfSdYJ8gp496RXZ0hTCuk5?= =?iso-8859-1?Q?JZCr6lbuwE92op79FxgkNoLIKMnn+KYxTZJ6ehSvXCm9t5yO/PFAsu9m2E?= =?iso-8859-1?Q?IlTgurqN6yX7RtjQF2bcvmJQj5Ci16K3Hvw7e4sG/8tiKYmzgaOJ/cFOmF?= =?iso-8859-1?Q?iE018ak0QWGxgCxkd/Ep7cHldETBiwAc+48ExCqBuV5loDX/pPfd+bjGXN?= =?iso-8859-1?Q?MV1/L11O9M0cg6jJCwtXHvHkOIzo9LWfaZGTssI11efEdtUYwBjNy/DKVu?= =?iso-8859-1?Q?vyobLboil0k0iW9y6u73KMqRzy9kqY7G8goiKNAzUrMH4PkfUMFowFeaG1?= =?iso-8859-1?Q?1LF6s+HYbmtNSGX6?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?YYOwY1AdiA/55xJU35VlTZvF9KGI5h4zrbSOe50Bg+W3SDGrU9f6a3J3Il?= =?iso-8859-1?Q?euhDrIcq5PutBuw7wllOHZX+cIegnaSrF0SbaTaA81Yo7PTnJC5aNOTSkQ?= =?iso-8859-1?Q?M6sFLxrD2j404NQI0bLqolPw02Uk++XjcMK79N7hRA+z9ek5+z83KP94jo?= =?iso-8859-1?Q?Js4jhRJXSL2gaAfIIqh5c7vdyiJykqUgFtzUloX0HLnvr9yh45USmg248q?= =?iso-8859-1?Q?E3aVEQrrXVoSwAFmDbsvpHoJvee+xaH3zUN54dTz8dXTCIhF6FOa6L4RGG?= =?iso-8859-1?Q?UNFIJTX4ERav15LCpyKfX2gm3b2O2TmuNOJXXhdmfy3Ec88vt0HbGpF6z+?= =?iso-8859-1?Q?2M7KFSwaKtMPZoMWVkjrGRP+3bUypzjC2Q5qYD76llhZezJp3HU091csRp?= =?iso-8859-1?Q?0dZZS0JlkiCuKiJId6jJ9KdcF6KGkJnAYATQ0+BevJbO2+bkKZF6D43MUx?= =?iso-8859-1?Q?llXEAoGMCy9g0MRZiapcJQB0RXGvkTB0uE7CFIqfZ8JLWBXfjm7iRUJnYB?= =?iso-8859-1?Q?/JMGBICL4iXMmUGWHunmOYXShFDW24wENZeztUa4HHFSCwpMj64c5FTMVO?= =?iso-8859-1?Q?neiLavyJsUl/P1GYzFQhbr9xWh89aBbk3T8aAnfC0PIxe3S91EUP5goiot?= =?iso-8859-1?Q?OeKfjUpHCsAx4T9lYr+sJ6ZiVUA1ojBWRncrxJkCGG5EN3bB+7GC8wTMLL?= =?iso-8859-1?Q?TL/x+AJxcILN1+UvXbZJdbOsf3vm0B6/hAHxmS2niAwhuYeoBxe+r3zxVu?= =?iso-8859-1?Q?txKK2nfMLdYA7/RJUxd74NTW5XvLc9q+KbnAbPpqNx4O6cyBfzojBeCnYP?= =?iso-8859-1?Q?ugvxu5sKOnwzL8wcBqStcX79anXVfnQK0WTghncCuyI8mN1F43DQ4K1k/u?= =?iso-8859-1?Q?b/xsQ8ZI5iJbDuu5mh6/7zMFNC2/JbWHbFgYCjCdMS0/SOL8Dxu+CliGiv?= =?iso-8859-1?Q?2h5tzQBP4mwJEUq+PyWKpUlKj02zCZ6PpesbP7cdPGu2PXLMzPbqvYaiR0?= =?iso-8859-1?Q?SrzLButTU0g553bnvWcwetzvdgfhvcFaKxOOsnSki8UeAAbHp5w93JHijE?= =?iso-8859-1?Q?eLgSuEQvjPOHeaTV48zQ09byOkJwlDpYooRZk1in4InO3EgwRHNJUTq+H0?= =?iso-8859-1?Q?t9XdUvpHRKopM7Uy+iBXCQx3QA1u6FWXiNWkXBcleaw5x23D59GE5D5wUM?= =?iso-8859-1?Q?tb17VZ5Fsul+iZUZjWDOOfp5Me80/zHzAxFkr5D/LuOmDjPXOMnB3z06Na?= =?iso-8859-1?Q?iSQeFOgLZJOIxc/zI0TSyi+MYFE6r0xFHfiv4KalfyN4CM4NpjvvOCIw4S?= =?iso-8859-1?Q?Rl1xy4QfXF3agY8LmF0XiNrmrgheBssApwZFr2Jg3JuenrZJeIh1j8IhIy?= =?iso-8859-1?Q?6NLcsaVT2oeDJEbVlKIETaa6CgZ9Zglz8PkB8gIT3RTuM2CKp8Vb/qk/tr?= =?iso-8859-1?Q?XQT1yuq6YW3d1rmQ+dPLPhtzdIvhE0Y2X9gIwgZcdjgYKeGwWfm7UOJoZW?= =?iso-8859-1?Q?bLUTin6J2TRrpUTP33+OXQTEuHTVBqtwbQ2ZYyfmJTlLNyCLHij1jwdKyO?= =?iso-8859-1?Q?kQPuXAQAoA6UVdmfpwi6Guqyd/+u4qFATMw84LCo66lBWjB66yRAqjje9x?= =?iso-8859-1?Q?6mar/oQMZHEcZR7oPajKxcv4DhMI0KeC9Spc6jJahXK65APATBgHDuJQ?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 6fd8fad3-541b-4e01-eb99-08dd2050453a X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 17:12:09.0462 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jSwqhsr2lofjCWiUwFqPEOtyXvkYKC7OvDDlRdWOuLUv42ewD/lylbToHqA1+PwK22X1O5myE0vps1xTcOIrvqBznjfTIoQlU/n1J+pgeyk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7752 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Dec 19, 2024 at 04:59:33PM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Wednesday, 27 November 2024 12.07 > > > > On Wed, Nov 27, 2024 at 11:53:50AM +0100, Mattias Rönnblom wrote: > > > On 2024-11-27 11:38, Bruce Richardson wrote: > > > > On Wed, Nov 27, 2024 at 11:03:31AM +0100, Mattias Rönnblom wrote: > > > > > Hi. > > > > > > > > > > Consider the following situation: > > > > > > > > > > An application does > > > > > > > > > > rte_event_eth_tx_adapter_enqueue() > > > > > > > > > > and due to back-pressure or some other reason not all > > events/packets could > > > > > be enqueued, and a count lower than the nb_events input parameter > > is > > > > > returned. > > > > > > > > > > The API says that "/../ the remaining events at the end of ev[] > > are not > > > > > consumed and the caller has to take care of them /../". > > > > > > > > > > May an event device rearrange the ev array so that any enqueue > > failures are > > > > > put last in the ev array? > > > > > > > > > > In other words: does the "at the end of ev[]" mean "at the end of > > ev[] as > > > > > the call has completed", or is the event array supposed to be > > untouched, and > > > > > thus the same events are at the end both before and after the > > call. > > > > > > > > > > The ev array pointer is not const, so from that perspective it > > may be > > > > > modified. > > > > > > > > > > This situation may occur for example the bonding driver is used > > under the > > > > > hood. The bonding driver does this kind of rearrangements on the > > ethdev > > > > > level. > > > > > > > > > > > > > Interesting question. I tend to think that we should not proclude > > this > > > > reordering, as it should allow e.g an eventdev which is short on > > space to > > > > selectively enqueue only the high priority events. > > > > > > > > > > Allowing reordering may be a little surprising to the user. At least > > it > > > would be for me. > > > > > > Other eventdev APIs enqueue do not allow this kind of reordering > > (with > > > const-marked arrays). > > > > > > > That is a good point. I forgot that the events are directly passed to > > the > > enqueue functions rather than being passed as pointers, which could > > then be > > reordered without modifying the underlying events. > > > > > That said, I lean toward agreeing with you, since it will solve the > > ethdev > > > tx_burst() mapping issue mentioned. > > > > > > > If enabling this solves a real problem, then let's allow it, despite > > the > > inconsistency in the APIs. Again, though, we need to to call this out > > in > > the docs very prominently to avoid surprises. > > > > Alternatively, do we want to add a separate API that explicitly allows > > reordering, and update the existing API to have a const value > > parameter? > > For drivers that don't implement the reordering they can just not > > provide > > the reordering function and the non-reorder version can be used > > transparently instead. > > IMHO, allowing reordering with the current API would break the developer's reasonable expectations of the API. > Breaking reasonable expectations could be considered an API break. > > Some application may have a parallel array with metadata about the events. > If the events are reordered (and the last N of them deferred to the application to process), the application can no longer index into the metadata array (to process the metadata of the deferred events). > > For reference, consider the SORING proposed by Konstantin. > > Regarding "const": > It's my impression that "const" is missing in lots of APIs where the parameter must not be modified. +1 to this. Fortunately, if we find ones where it is missing, it's not an ABI or API break to add in the missing const clarification. Therefore, let's add these consts in whenever we spot them missing! > So, developers cannot rely on "const" as an indication if a passed parameter might be modified or not. > Obviously, "const" cannot be modified. But no "const" does not imply that the parameter is contractually modifiable by the function. > Or more specifically, the develop cannot derive any information from the absence of const in our APIs - the parameters might be modified, but then again they may not. Sometimes this causes problems, where application code wants to have const-correctness but is blocked by a DPDK function where it logically should not modify parameters e.g. a configure function, but is not explicitly committing via const not to. /Bruce