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 9F59F431EE; Tue, 24 Oct 2023 10:10:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6A257402E1; Tue, 24 Oct 2023 10:10:54 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 0E2684021D for ; Tue, 24 Oct 2023 10:10:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698135052; x=1729671052; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=x9L5VOu5jJ3hy2C+jDf8CdOaTvZgS+w3rzKCJOvnDpU=; b=YIU+RoAr9H2rdusHglewXK2UwBU2iVVpvBlNO3lPUbtkILDh+/pfiVeC I87jF0pb5LC2vrHHUcv9ZUhGo5JvQBupbywhIUz86873Mm/fhMhU0Tu46 bNw6rVQBX+YgI6jLd3PmRXRqSXf5zGAoFo88joasfwTMAEBogCZP4xSN6 tFR7ZyQTJ6aD3ieeYA/4RVlVoHXJfLXTGG48mkUS0iREQun7BPskvtgJz WV2zZauxdFdziuUwi7FFa87PBwwiyQSdroWkwgx9v8HPuRBM72hXXekEO bp9+unL1CnWOeNX6j/OHDzxnx6eJHa4AwTzltH9b1GCuDzmu/fPNTajyd w==; X-IronPort-AV: E=McAfee;i="6600,9927,10872"; a="451239541" X-IronPort-AV: E=Sophos;i="6.03,247,1694761200"; d="scan'208";a="451239541" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 01:10:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10872"; a="734956205" X-IronPort-AV: E=Sophos;i="6.03,247,1694761200"; d="scan'208";a="734956205" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga006.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 24 Oct 2023 01:10:50 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Tue, 24 Oct 2023 01:10:50 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Tue, 24 Oct 2023 01:10:49 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Tue, 24 Oct 2023 01:10:49 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.32; Tue, 24 Oct 2023 01:10:49 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JNPHLpVAGeC7uLM2MBQaALWtWIDwblWl8bpAANPLwThQ5P1lfuA0PeKphDTnOgqiUuiQtBK3wa786Ju4/CSCzltHM1F+mB+uHueFG3e3Pw899knKg7VWQsFYUBFZTiAlfVBMbB2SKuZBRnfNHnJasOMwb/DnkXax8UR9J23JR0cXXnUA6pgxUIefg2ILL/QU+il258gn9WIxdSWETOFW3f39D9tqzS0GIuVzHuFakbVJM9o4c80yKfcpHP+ZL7NgxyAEOsMk22SLD3rauIhds+PrRkYaaWsHWhFDn8eIieqokHipPv+7AENT0909VYT1CcrdkkVuK+oqvrXLAdrXxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=ZpFfSfniQblz1EZi3qikRfczG9GmRNFeJ0xkiWPGSVw=; b=KgbCwai3aNvbpVqg9LgE5okmL/j+dmw+uKWb3r6/mrpHXcriCDlCHfl/kEHIplByPMqyH+y7q3VW7M9O1aV8OEml4Igx+Q2Elt/gW2jpXWhEFWcHsJLDF5AUhFwcnQsgX7vejUtzqw0wJUhYEmFypbjpqddjajDBtB0z4cIm5aPSK21Fc/jokkjtgTba81Uhkv3eKLBHzPnblmfYqDjxfCl0bMJQaNeilbW/y3UhGvVhwnDs6hQ6nmDBSjkJ60q6IW7/YsTgtUpFMhmax7q2ZEE2U2r6rMukDFnSFAfBsTVWqmHdHf50gjdR30iFgnVtsQd1gz6krsz4hLCO2fDwCQ== 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 SA0PR11MB4621.namprd11.prod.outlook.com (2603:10b6:806:72::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.33; Tue, 24 Oct 2023 08:10:41 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::d70b:11a0:d28f:ec44]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::d70b:11a0:d28f:ec44%6]) with mapi id 15.20.6907.032; Tue, 24 Oct 2023 08:10:34 +0000 Date: Tue, 24 Oct 2023 09:10:30 +0100 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= CC: "dev@dpdk.org" , Jerin Jacob , "Peter Nilsson" , , Harry van Haaren , Abdullah Sevincer Subject: Re: Eventdev dequeue-enqueue event correlation Message-ID: References: Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: DUZPR01CA0227.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b4::15) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|SA0PR11MB4621:EE_ X-MS-Office365-Filtering-Correlation-Id: 4da5f874-89f6-4b99-e271-08dbd468b2e4 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; X-Microsoft-Antispam-Message-Info: gzpU0XeSWSG3FGa9sR1L/6B9/O0hOOl/dv9d/WzgNiZbKxSc5THrejFlPGXTTxA6ye2mJhFvVwOyv97ByYrviJR9H5f9GSkAyr8bgFGSzQIuvuMCEXw4szfpuaqHq8oHURpc3maeRy1O/nkcazF8ogRGDmFAW7yZfGI9byQlBz3LRtVowiIZqbtlFVXezz0n5uNgc2FyJw8JnHeAa3XG1yeOCO5YWNB1quS+M2KaYaoVwUsI2cfSbd2r6kTeNsknQFWKPNYK1kgl6Acso7yUg3Yq9/q9SmHAlzVAWuyhldQgWKea2zV7arXk/9b0S8VLX447UkB2zxBASjX2EJlwJUXyd1UK67CVoxvS7Fm29uO/d7vihiMBOFs5P/aglo0Sg/QqXKAZAeJpjcTvceSdu6ryps3Vg2N4akQ/Rjqaz49unLYaSuFW46CkxvVUSyJhY901uCqTOpODbKgt4tPkocuvGnxyHz8TfSQgEoOgnx2Ejrm+r03tz60yaFzlyt0m/t5L7YN/IWVSYbF6o0Rseqk+lwzbnY25aHvDtc3P+UImHZzJ3hyvGw6wO/vKK62j 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:(13230031)(396003)(136003)(346002)(366004)(376002)(39860400002)(230922051799003)(1800799009)(451199024)(186009)(64100799003)(2906002)(41300700001)(38100700002)(3480700007)(316002)(66946007)(66476007)(54906003)(6916009)(66556008)(296002)(6506007)(82960400001)(107886003)(478600001)(6666004)(6512007)(6486002)(83380400001)(66574015)(44832011)(86362001)(5660300002)(4326008)(8936002)(8676002)(26005); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?Ze6W1kWVf6+/dyK4AjgH+QoMCtExiER29iMz7TeFELwmlEUKrf7dK33QRC?= =?iso-8859-1?Q?zjDcojQXon9nCh8KPe6uPE3xv4Ax8GJobCVTP+2Xdob9dxgIypcoZoB47K?= =?iso-8859-1?Q?7n0Qs8vbFo0VImgG8as5pmv79hAkXVZCWal3SBaOZHQmVJ9xtMaFZ3tGOa?= =?iso-8859-1?Q?XPwIj7+Gdp5DkFm5/m5mD8yzTc5a+wFgSi/tZ3y4Zb4OXADH6KbKRLalvW?= =?iso-8859-1?Q?RxS81K8XSEXahGdlK8NgxSutk88W3eTHxMUa5Vewg1JUScljVmCvweXM19?= =?iso-8859-1?Q?l4Eby6mIa7XK1Lq0J3MI+xgLCqVSSsDEJnYhHmK8BUxALcNYZ5BS7p9Pcf?= =?iso-8859-1?Q?cLWBEqcFgtuO7az5i1hpp9/F3RWX0UjGGcoqG7Nw2a7wG42s83hGaXlctC?= =?iso-8859-1?Q?RoAFs3aq2mTtiPmJ7V3s50fgFtVuGO1lSl/RPyliTPli9BMZmRcyLbuApi?= =?iso-8859-1?Q?h0WbT8z7zj9EgD1k8vg5OmcmROoS4q9udaevnRovQkQXkNz4+w2c/qV2G/?= =?iso-8859-1?Q?F418gQjghN/vo1siZeVavvRoMPSsDGVBYqpJ5K6q+QV2HNfuVZYaD0QR4F?= =?iso-8859-1?Q?l14nzmkByud5yFWL4m0vqMCax3eziGSJSHACTB7teplnudaNfL+VDUL9T4?= =?iso-8859-1?Q?18QO3jqUoYrYcS+G07YYixPnC1gmpCefkmPW5EvNn0UUnl0+9rUY90ceoo?= =?iso-8859-1?Q?SfMUfak1KGZrRVarfkvWx6L0QGn+/XTlGGxvhzdiH9RRolduxKFtHnrRxf?= =?iso-8859-1?Q?OZoceXY0hF9AFgLqna9x7edLnsetM2hlEOVTVgr2OMXgnNpIudodMECEXM?= =?iso-8859-1?Q?Kp+D9/oPxPPyENzprEZibA6nQ/kCMWkhfpiqFxS+qW6Wc6PludEdP1dY9q?= =?iso-8859-1?Q?tbIpV668bYhHbP7kM1BuNB9BU1pfeGFY6jyn4TqRQbCiOqN/dZLB+5lBpl?= =?iso-8859-1?Q?3Q9+EpCyiXtLokLEuvzZMkmlbWKLp2DzDONKMUuJWYuJl9LK+q+iKoxsPE?= =?iso-8859-1?Q?oLaZjd0t7kivj+235M4EEWsrdiL29+BzzVxjCI0UJlN0emE/yIr6bmQBlx?= =?iso-8859-1?Q?jX7eS/Nm1B5sMomFy+z39XF52rzBc/J93VuLO7Y2ZtXxHxVtZap8Niz04t?= =?iso-8859-1?Q?0Lcnxd7cI7L/N7yxvUfmuO4LCYHkN/tb/xfdCaLunyDH48QBOsEV5tgHSX?= =?iso-8859-1?Q?kPUGK15OUID/RBh/Ht7GAHFCkVwHqEstRKkd8ZV3HZvE+nkpoVt6ay318L?= =?iso-8859-1?Q?l18fS81KNnHLew5XONa8wjQrwCiVug0xIn0sRohZv1m+zq1wYfxjuBRWYJ?= =?iso-8859-1?Q?Jd+ZzmNo8+XRfPzc6amQui8uhuUYZm+QGp0GTG8MHyQntcuNwZfe9nw819?= =?iso-8859-1?Q?pVKNY+Yq8Cdg3vYZB5HgWVAVYU/U9OhytGEVRn00ZDoZW0GN+sTA56/TrI?= =?iso-8859-1?Q?oy6WFjH6eNKIrCV6GKvY79XT6NvHYQM6VSumk5yrkKV1oaby7Xl9+yOrpB?= =?iso-8859-1?Q?GxPEvRP3jVD/55YP5XDmUSwmzNQ49aBsjz8u9GAC2m5D0R8dPqWZLOOpaH?= =?iso-8859-1?Q?Sg3m2qu3NGFHvbDIQzzK93YJL0fmEirzo+bgyJr3INaGNxxpD+JnXp3UnA?= =?iso-8859-1?Q?rf5osX9mVmlAVJnRJtZy56/BFioMRzB6s/wFnfvgpij+vb38xh/0/v5g?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 4da5f874-89f6-4b99-e271-08dbd468b2e4 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2023 08:10:34.8488 (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: aH0nWKFzURR9Y++EkW5WYni9ohQVdJhqzqYcut7Qtl02aECJi3MNZG/+mfcQDr5EN1ZiKXMAveSs/dwo3ygMm0JiSr9bJMZXbP7V36xNKso= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4621 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 Mon, Oct 23, 2023 at 06:10:54PM +0200, Mattias Rönnblom wrote: > Hi. > > Consider an Eventdev app using atomic-type scheduling doing something like: > > struct rte_event events[3]; > > rte_event_dequeue_burst(dev_id, port_id, events, 3, 0); > > /* Assume three events were dequeued, and the application decides > * it's best off to processing event 0 and 2 consecutively */ > > process(&events[0]); > process(&events[2]); > > events[0].queue_id++; > events[0].op = RTE_EVENT_OP_FORWARD; > events[2].queue_id++; > events[2].op = RTE_EVENT_OP_FORWARD; > > rte_event_enqueue_burst(dev_id, port_id, &events[0], 1); > rte_event_enqueue_burst(dev_id, port_id, &events[2], 1); > > process(&events[1]); > events[1].queue_id++; > events[1].op = RTE_EVENT_OP_FORWARD; > > rte_event_enqueue_burst(dev_id, port_id, &events[1], 1); > > If one would just read the Eventdev API spec, they might expect this to work > (especially since impl_opaque hints as potentially be useful for the purpose > of identifying events). > > However, on certain event devices, it doesn't (and maybe rightly so). If > event 0 and 2 belongs to the same flow (queue id + flow id pair), and event > 1 belongs to some other, then this other flow would be "unlocked" at the > point of the second enqueue operation (and thus be processed on some other > core, in parallel). The first flow would still be needlessly "locked". > > Such event devices require the order of the enqueued events to be the same > as the dequeued events, using RTE_EVENT_OP_RELEASE type events as "fillers" > for dropped events. > > Am I missing something in the Eventdev API documentation? > Much more likely is that the documentation is missing something. We should explicitly clarify this behaviour, as it's required by a number of drivers. > Could an event device use the impl_opaque field to track the identity of an > event (and thus relax ordering requirements) and still be complaint toward > the API? > Possibly, but the documentation also doesn't report that the impl_opaque field must be preserved between dequeue and enqueue. When forwarding a packet it's well possible for an app to extract an mbuf from a dequeued event and create a new event for sending it back in to the eventdev. For example, if the first stage post-RX is doing classify, it's entirely possible for every single field in the event header to be different for the event returned compared to dequeue (flow_id recomputed, event type/source adjusted, target queue_id and priority updated, op type changed to forward from new, etc. etc.). > What happens if a RTE_EVENT_OP_NEW event is inserted into the mix of > OP_FORWARD and OP_RELEASE type events being enqueued? Again I'm not clear on > what the API says, if anything. > OP_NEW should have no effect on the "history-list" of events previousl dequeued. Again, our docs should clarify that explicitly. Thanks for calling all this out. /Bruce