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 0282F431E4; Mon, 23 Oct 2023 18:10:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4AD9402CB; Mon, 23 Oct 2023 18:10:58 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 24C0D40275 for ; Mon, 23 Oct 2023 18:10:57 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BDEF41A21E for ; Mon, 23 Oct 2023 18:10:56 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id B258E1A21D; Mon, 23 Oct 2023 18:10:56 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.6 X-Spam-Score: -1.5 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 9277319E41; Mon, 23 Oct 2023 18:10:54 +0200 (CEST) Message-ID: Date: Mon, 23 Oct 2023 18:10:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "dev@dpdk.org" From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Subject: Eventdev dequeue-enqueue event correlation Cc: Jerin Jacob , Peter Nilsson , svante.jarvstrat@ericsson.com, Harry van Haaren , Abdullah Sevincer Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 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? 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? 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. Regards, Mattias