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 ADF2F45DB5; Wed, 27 Nov 2024 11:53:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7AF9E4021E; Wed, 27 Nov 2024 11:53:54 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id E3826400D6 for ; Wed, 27 Nov 2024 11:53:52 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A841DD707 for ; Wed, 27 Nov 2024 11:53:52 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 9C089D6CD; Wed, 27 Nov 2024 11:53:52 +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 020AED705; Wed, 27 Nov 2024 11:53:50 +0100 (CET) Message-ID: <24837b70-29fd-472a-aa1d-ab350d6ba5c8@lysator.liu.se> Date: Wed, 27 Nov 2024 11:53:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: rte_event_eth_tx_adapter_enqueue() short enqueue To: Bruce Richardson Cc: "dev@dpdk.org" , 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?= References: <903aa783-5956-4020-b2a0-48def17fe03f@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 said, I lean toward agreeing with you, since it will solve the ethdev tx_burst() mapping issue mentioned. > Only caveat is that if we do allow the reordering we clarify the > documentation to explicitly state that it is allowed. > > /Bruce