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 BCC38439A6; Tue, 23 Jan 2024 10:34:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 49F8C402C5; Tue, 23 Jan 2024 10:34:31 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) by mails.dpdk.org (Postfix) with ESMTP id 14C78402BD for ; Tue, 23 Jan 2024 10:34:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706002469; x=1737538469; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=kXwwyIxCT++Xupf6B9C3vYWs/ZvBg/xTR7ZqaSs0Q/o=; b=Sll9DeBsBWOgm0O5ILW/RGGFES3+YC0U0Dk4HrPVadS1biMgBa9IxCpB Kj+ExwLW03NLrU9bDo3ZGMixrx6h1Wwmgi7Aj5r5zBjjdjw8tQKiWZrzJ XVqj04VgfncliQvztBZp5/0rBwc4TjYhsNfx4ekBwhyCayJG3YD9JT4SB Rh9edQW8vg7sysnRH+9jWpXC5q//xJGaamPPF9iZ9Y818GPKJ3yGROu3Z b71Qjb6OVH/LIs3sk08HUj8T56DEPL9GxXQQPPbUIggqc+EKW5g1xhPlW edHV8vJAMoums4Oce4PfiqlPiahcRsbD2zmCnKjpVRrpArr86LYncMjJn w==; X-IronPort-AV: E=McAfee;i="6600,9927,10961"; a="1321121" X-IronPort-AV: E=Sophos;i="6.05,214,1701158400"; d="scan'208";a="1321121" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2024 01:34:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,214,1701158400"; d="scan'208";a="1611947" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmviesa004.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 23 Jan 2024 01:34:27 -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.35; Tue, 23 Jan 2024 01:34:25 -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.35 via Frontend Transport; Tue, 23 Jan 2024 01:34:25 -0800 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.169) 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.35; Tue, 23 Jan 2024 01:34:25 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CoUi24KFayKDnps6z8iGWqlD4vvwOJFA9T5cMBf+c+9QEpfyNMWRucf8w+5sTETgxxTgTyibGNAxZwDoolkEtnILHLpu/k1ig4DBxsYzFg7TkvX5pBxcsuE2G/r7Bg3OJMoLCYEAv1qILq2Tzygz5kEtrUf90zagHR8a6LH7gARWpx97aIo9f+s5ZXwSbe55NwPBpiWeVt3N8aWum5AwTUkxRTQNVyUTxVgai0q88+5xmEqt3PCpXzw+0UVwfR6S0qedwnPdjFDZqO8G1HgOnBhyfYN7/wMWtPD1VE1schlw9heFObyWJozjEChJkroudTdvK0g1HEfZ1oJN5Ot6Vw== 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=tvJ/gS6I+1tLZycd/LTuEPHK9Jou22GihKgBxV3GeFE=; b=YJ4PbYiesRmWW6ffrg2jg7T6zOSbLtQ+SNGmBQkYpcvP6gv309zdNowjCdlW2OZfFyu4IwbwfigIlSozPcmAbn9BsghbawfrloivwzcWyCvYqOLKacBjNrpw3qyskG93NAZ9FTw/n4O/NCb4XnASEWWvuBwsI1ZHsFPfJIGmStDmolX9pqt/qoQealIszsr76U8ECW1hzwJLJ2QflqNlTxixMdT6jd8eSvoUegFq4yXO2sWJYccqrVBx8hGZNpn2X5fG+8Jfaw6K/bwN778jB24KhkxRMvM9Zuk/6Z8T1GpYhGPBrllt+x88slP0mbij2X8AB5c0wC1b9t73KC+WUw== 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 SJ2PR11MB7427.namprd11.prod.outlook.com (2603:10b6:a03:4c1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7202.34; Tue, 23 Jan 2024 09:34:24 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::df88:b743:97f8:516c]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::df88:b743:97f8:516c%5]) with mapi id 15.20.7202.035; Tue, 23 Jan 2024 09:34:24 +0000 Date: Tue, 23 Jan 2024 09:34:18 +0000 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= CC: , , , , , , , Subject: Re: [PATCH v2 03/11] eventdev: update documentation on device capability flags Message-ID: References: <20240118134557.73172-1-bruce.richardson@intel.com> <20240119174346.108905-1-bruce.richardson@intel.com> <20240119174346.108905-4-bruce.richardson@intel.com> <93bed273-2ea3-48fe-adaa-0a546ab03730@lysator.liu.se> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93bed273-2ea3-48fe-adaa-0a546ab03730@lysator.liu.se> X-ClientProxiedBy: DUZPR01CA0088.eurprd01.prod.exchangelabs.com (2603:10a6:10:46a::14) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|SJ2PR11MB7427:EE_ X-MS-Office365-Filtering-Correlation-Id: 731d05c2-dc16-4f91-2a3f-08dc1bf67c0e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: t9mNCaIUd1d3yMMI6tCbXJWS59v4CSgzzbCaZTlYYsPsqBmKBPmJ02ajxrpf1lMuuumWjzXOhOG31S595ca6L6IbdTu36Z+a17IaG6/Da8WfZJfr1W3oM5qDa38+5uvgJXU/QbBxCg8MIZohaFol9RjjXrWUWxwnIoop4zK9eLAN2f+uPGktDeV7lsNOxO0P6AMqwUO4OWFVWpEXu0rYb+2wYAzIvkqT9XqSUpc30971in/iEzbNro9x8CDYJeCU+L0kg7XJZH3RQyNjy2eOh1colh7YeP38BtBlhYXAYLxm3wNXyPg03WjA2VfuLgQxFUYJqcwKFq95U0BGmJcO/9+FMFlAxGoosSc/eyk/IM4EN+10ycK8vUa4J5GNXVJ5kgvijcUj0wvzO4eVzS9/+6jFkOt8KvFbF15ksyhYMqwbHRFKwPtL9rZ9DGLR+NTLGk0+IQSOll1qD39uGEKl4+cxh6i3xWATplcUhFnd11WZvDO9htN6fk1ArVyPHwa7FJfCpMNa5bt3zVvFEsPZ22zdukeKJFM7jz7T9T2+Ujf5UIZcC83YyXIbzJYYFI6g 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)(136003)(366004)(346002)(376002)(39860400002)(396003)(230922051799003)(1800799012)(64100799003)(451199024)(186009)(6512007)(53546011)(6506007)(66574015)(26005)(83380400001)(107886003)(41300700001)(66476007)(4326008)(8676002)(296002)(316002)(6916009)(5660300002)(15650500001)(8936002)(2906002)(86362001)(44832011)(66946007)(66556008)(6666004)(6486002)(478600001)(82960400001)(38100700002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?LJT1dNGnhAqrYVQs6oxQbZdyww28TTvKHcUhea2zJEuwm8IeghGlA0MSnz?= =?iso-8859-1?Q?vEB6G1kN5PhZsFLUmBXx+yTSyXShTIGoWKt7S5BIluvsfMdGy/X66PzPfE?= =?iso-8859-1?Q?WgOWnlOtehsuwHvF2UxMaLaUXiclZJkYsVCr4rBvao5z8mGJSop0eQPLOs?= =?iso-8859-1?Q?o3Wzn3NxpMADZrWGKO09TZKQGElaugf66/LE3HWmW3EIN6MvBin5RpYM8B?= =?iso-8859-1?Q?YKh5JQWxlPwrmfA73IwGr5az8GJB4a6YZJfVTv0yck1lcsoxaGPlwAgD4k?= =?iso-8859-1?Q?k7xKQzfT1egEacF1xz5UgzwD3ovFjzqKJYJrG9y2CMOjZbuwfzWDoVla7s?= =?iso-8859-1?Q?nbllchpmAPkh6w6L4XzadxNIlV4ryP9wrP270qS1jkz852fZKKNqQHBR5G?= =?iso-8859-1?Q?F3hjIg4f1yF9gLJqmfzjPssZAuuKKzGVkPZHi9eNmSRL60tESk0WEB/L6b?= =?iso-8859-1?Q?wF9ujzfqXor5iRjI87fvDBa6634F2lbtJ2r9ROicABdFZH67QyN6Bz68pi?= =?iso-8859-1?Q?/spKNX3UQo0neREQqQ2F3UsRGTgWYkzbFLONjvgfCrWQyXtAX4uEvRHerT?= =?iso-8859-1?Q?PeWa0kEi1WCOaFTHeNrhHRmlb8N5R3tbhWWmbZOcwAQkIa2XQCaQCjwoC+?= =?iso-8859-1?Q?w0z61fnh0QBkKcsdu68+FpbeWzcFKM5KJZMm41LStaKOJJKf6STp26PYJ2?= =?iso-8859-1?Q?mH//J7AeHFSBl6jp/QPhZutXUdna1yCo73tX6bMwsb97Bx9iuaUI8p/h9+?= =?iso-8859-1?Q?O3jT2QbK61MqxOirknixABKVFyeeRIJqcSBnIFXOpOPZjve6af80vw75fO?= =?iso-8859-1?Q?+Gm86Q3CN0rtknxUAp8GWtGrr7LFGWXMdh/NlwyQyl4lFTICqbl333edet?= =?iso-8859-1?Q?T4+EPJ+malvr0ALbr+XNzcBq+v/uAv3fxksSBqQf3uiZ5+OrmLh32YIHe4?= =?iso-8859-1?Q?sE7iCU9j0iQaFgU9+SLamXB1ZT0yxN27ov8+nIzygH3Opfr/Nfm/9z2vSH?= =?iso-8859-1?Q?Cv2VslsnqzGhSfJ7bmJMBTf/prA/0X9JEPfkWooSnIuhZLCXZ+knHs5WqP?= =?iso-8859-1?Q?c8qx1EiLDUKi/Xo6CkIKKlKMD+c2v8YFunxRy1NkAY1usFR8479EZ133G4?= =?iso-8859-1?Q?5BWoX23wzwhLCWAgyKoBjI+iZpCG4kSolX0E1Z/1uq4ma8aqlPN6nFzrLN?= =?iso-8859-1?Q?dzsGxf8qZ4mUKCqP64EwWvrEFKXSQSumRH400BKcuyJERcqfYS6mC0f1UM?= =?iso-8859-1?Q?xw8GK2jRt11+vkny9j/PIZaoh5XMFrK0IA+sdoweROtoRACQORaIFTUeSp?= =?iso-8859-1?Q?bJNFTDKQJYtqz4E4Prr4YhHwENlTgGmZxcpF/Gr6bHV7MtlRG4MCN33BDh?= =?iso-8859-1?Q?xgAoS+Jzz6x4uy1K3eJrq/+LZrQj1eiQpEjYljsZiP3iIoAc0u80s9U6HR?= =?iso-8859-1?Q?L8AR90fOIEIdZeE8p7Du9llEJ/katLlQLIOxn5QUPw0dO35nmoP6n+VPlE?= =?iso-8859-1?Q?Wp01PFyoGToYuRF1/trnKiqUi6XVxqX4C1inlgu+hSG5PaLyZSlhdNL45/?= =?iso-8859-1?Q?gPMwUsE3LjP+jFrRrsx7khYW2C8rOboj6KDH58DWvpfzDnBM5rbeZHGQbk?= =?iso-8859-1?Q?buWqZe8mBc8E9kmv8rp9qJ3IdvUc/VzCPZ9rIspzyWw6aIuX1VIIItqg?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 731d05c2-dc16-4f91-2a3f-08dc1bf67c0e X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2024 09:34:23.9621 (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: 4dPOSfCMQv96JDuJ8K5z6Yk2Il+Dc35jDzB+4W6SMDDFlrNDO3nYAXyLX7lBXehleVjdWgwksX5ZZS2keRkFpSDwF3x2xfw4OCt3LNBx1+g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7427 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 Tue, Jan 23, 2024 at 10:18:53AM +0100, Mattias Rönnblom wrote: > On 2024-01-19 18:43, Bruce Richardson wrote: > > Update the device capability docs, to: > > > > * include more cross-references > > * split longer text into paragraphs, in most cases with each flag having > > a single-line summary at the start of the doc block > > * general comment rewording and clarification as appropriate > > > > Signed-off-by: Bruce Richardson > > --- > > lib/eventdev/rte_eventdev.h | 130 ++++++++++++++++++++++++++---------- > > 1 file changed, 93 insertions(+), 37 deletions(-) > > > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h > > index 949e957f1b..57a2791946 100644 > > --- a/lib/eventdev/rte_eventdev.h > > +++ b/lib/eventdev/rte_eventdev.h > > @@ -243,143 +243,199 @@ struct rte_event; > > /* Event device capability bitmap flags */ > > #define RTE_EVENT_DEV_CAP_QUEUE_QOS (1ULL << 0) > > /**< Event scheduling prioritization is based on the priority and weight > > - * associated with each event queue. Events from a queue with highest priority > > - * is scheduled first. If the queues are of same priority, weight of the queues > > + * associated with each event queue. > > + * > > + * Events from a queue with highest priority > > + * are scheduled first. If the queues are of same priority, weight of the queues > > * are considered to select a queue in a weighted round robin fashion. > > * Subsequent dequeue calls from an event port could see events from the same > > * event queue, if the queue is configured with an affinity count. Affinity > > * count is the number of subsequent dequeue calls, in which an event port > > * should use the same event queue if the queue is non-empty > > * > > Maybe the subject for a future documentation patch: but what happens to > order maintenance for different-priority events. I've always assumed events > on atomic/ordered queues where only ordered in the flow_id within the same > priority, not flow_id alone. > Agree with this. If events with the same flow_id are spread across two priority levels, they are not the same flow. I'll try and clarify this in v3. > > + * NOTE: A device may use both queue prioritization and event prioritization > > + * (@ref RTE_EVENT_DEV_CAP_EVENT_QOS capability) when making packet scheduling decisions. > > + * > > * @see rte_event_queue_setup(), rte_event_queue_attr_set() > > */ > > #define RTE_EVENT_DEV_CAP_EVENT_QOS (1ULL << 1) > > /**< Event scheduling prioritization is based on the priority associated with > > - * each event. Priority of each event is supplied in *rte_event* structure > > + * each event. > > + * > > + * Priority of each event is supplied in *rte_event* structure > > * on each enqueue operation. > > + * If this capability is not set, the priority field of the event structure > > + * is ignored for each event. > > * > > + * NOTE: A device may use both queue prioritization (@ref RTE_EVENT_DEV_CAP_QUEUE_QOS capability) > > + * and event prioritization when making packet scheduling decisions. > > + > > * @see rte_event_enqueue_burst() > > */ > > #define RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED (1ULL << 2) > > /**< Event device operates in distributed scheduling mode. > > + * > > * In distributed scheduling mode, event scheduling happens in HW or > > - * rte_event_dequeue_burst() or the combination of these two. > > + * rte_event_dequeue_burst() / rte_event_enqueue_burst() or the combination of these two. > > * If the flag is not set then eventdev is centralized and thus needs a > > * dedicated service core that acts as a scheduling thread . > > * > > - * @see rte_event_dequeue_burst() > > + * @see rte_event_dev_service_id_get > > */ > > #define RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES (1ULL << 3) > > /**< Event device is capable of enqueuing events of any type to any queue. > > + * > > * If this capability is not set, the queue only supports events of the > > - * *RTE_SCHED_TYPE_* type that it was created with. > > + * *RTE_SCHED_TYPE_* type that it was created with. > > + * Any events of other types scheduled to the queue will handled in an > > + * implementation-dependent manner. They may be dropped by the > > + * event device, or enqueued with the scheduling type adjusted to the > > + * correct/supported value. > > Having the application setting sched_type when it was already set on a the > level of the queue never made sense to me. > > I can't see any reasons why this field shouldn't be ignored by the event > device on non-RTE_EVENT_QUEUE_CFG_ALL_TYPES queues. > > If the behavior is indeed undefined, I think it's better to just say > "undefined" rather than the above speculation. > +1, I completely agree with ignoring for fixed-type queues. Saves drivers checking. The reason I didn't put that in was a desire to minimise possible semantic changes, but I think later on the patchset my desire to avoid such changes waned and I have included more "severe" changes than I originally would like. [The changes in "release" events on ordered queues being the big one I'm aware of, that I should really have held back to a separate dedicated patch/patchset] Unless someone objects, I'll update that in a v3. However, many of these subtle changes may mean updates to drivers, so how we go about clarifying things and getting drivers compatible is something we need to think about. We should probably target 24.11 as the point at which we should have all behaviour clarified, and drivers updated if possible. There are so many point of ambiguity - especially in error cases - I expect we may have some work to do to get all aligned. /Bruce