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 92E4C45DB5; Wed, 27 Nov 2024 11:03:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54EFC4021E; Wed, 27 Nov 2024 11:03:36 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 6C900400D6 for ; Wed, 27 Nov 2024 11:03:34 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F0919D359 for ; Wed, 27 Nov 2024 11:03:33 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E52A8D4A2; Wed, 27 Nov 2024 11:03:33 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.85] (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 X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id B4595D39D; Wed, 27 Nov 2024 11:03:31 +0100 (CET) Message-ID: <903aa783-5956-4020-b2a0-48def17fe03f@lysator.liu.se> Date: Wed, 27 Nov 2024 11:03:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "dev@dpdk.org" Cc: Jerin Jacob Kollanukkaran , =?UTF-8?Q?Daniel_=C3=96stman?= , Naga Harish K S V , nils.wiberg@ericsson.com, gyumin.hwang@ericsson.com, changshik.lee@ericsson.com, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Subject: rte_event_eth_tx_adapter_enqueue() short enqueue 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 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. Thanks, Mattias