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 6B1CA45EED; Thu, 19 Dec 2024 16:59:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F288240265; Thu, 19 Dec 2024 16:59:37 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 44D7A4025F for ; Thu, 19 Dec 2024 16:59:36 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id E21C520A77; Thu, 19 Dec 2024 16:59:35 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: rte_event_eth_tx_adapter_enqueue() short enqueue Date: Thu, 19 Dec 2024 16:59:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F96A@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rte_event_eth_tx_adapter_enqueue() short enqueue Thread-Index: AdtAvJxYZCn9fBgxSTuCRtA4tR1W+gRb9HAQ References: <903aa783-5956-4020-b2a0-48def17fe03f@lysator.liu.se> <24837b70-29fd-472a-aa1d-ab350d6ba5c8@lysator.liu.se> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , =?iso-8859-1?Q?Mattias_R=F6nnblom?= Cc: , "Jerin Jacob Kollanukkaran" , =?iso-8859-1?Q?Daniel_=D6stman?= , "Naga Harish K S V" , , , , =?iso-8859-1?Q?Mattias_R=F6nnblom?= 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 > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Wednesday, 27 November 2024 12.07 >=20 > On Wed, Nov 27, 2024 at 11:53:50AM +0100, Mattias R=F6nnblom wrote: > > On 2024-11-27 11:38, Bruce Richardson wrote: > > > On Wed, Nov 27, 2024 at 11:03:31AM +0100, Mattias R=F6nnblom = 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). > > >=20 > That is a good point. I forgot that the events are directly passed to > the > enqueue functions rather than being passed as pointers, which could > then be > reordered without modifying the underlying events. >=20 > > That said, I lean toward agreeing with you, since it will solve the > ethdev > > tx_burst() mapping issue mentioned. > > >=20 > If enabling this solves a real problem, then let's allow it, despite > the > inconsistency in the APIs. Again, though, we need to to call this out > in > the docs very prominently to avoid surprises. >=20 > Alternatively, do we want to add a separate API that explicitly allows > reordering, and update the existing API to have a const value > parameter? > For drivers that don't implement the reordering they can just not > provide > the reordering function and the non-reorder version can be used > transparently instead. IMHO, allowing reordering with the current API would break the = developer's reasonable expectations of the API. Breaking reasonable expectations could be considered an API break. Some application may have a parallel array with metadata about the = events. If the events are reordered (and the last N of them deferred to the = application to process), the application can no longer index into the = metadata array (to process the metadata of the deferred events). For reference, consider the SORING proposed by Konstantin. Regarding "const": It's my impression that "const" is missing in lots of APIs where the = parameter must not be modified. So, developers cannot rely on "const" as an indication if a passed = parameter might be modified or not. Obviously, "const" cannot be modified. But no "const" does not imply = that the parameter is contractually modifiable by the function.