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 8280A46ABB; Mon, 7 Jul 2025 13:57:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 454D640287; Mon, 7 Jul 2025 13:57:28 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 049604025D for ; Mon, 7 Jul 2025 13:57:27 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C506516BE3 for ; Mon, 7 Jul 2025 13:57:26 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id B81D116CC1; Mon, 7 Jul 2025 13:57:26 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=4.0.1 X-Spam-Score: -1.0 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 4C2F816B6C; Mon, 7 Jul 2025 13:57:25 +0200 (CEST) Message-ID: <3c82f05d-216d-428f-a315-30457da0f94c@lysator.liu.se> Date: Mon, 7 Jul 2025 13:57:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] event/eth_tx: prefetch mbuf headers To: "Naga Harish K, S V" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "dev@dpdk.org" Cc: Jerin Jacob , Peter Nilsson References: <20250328054339.489914-1-mattias.ronnblom@ericsson.com> 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 2025-07-07 11:00, Naga Harish K, S V wrote: > > >> -----Original Message----- >> From: Mattias Rönnblom >> Sent: Thursday, July 3, 2025 1:50 AM >> To: Naga Harish K, S V ; Mattias Rönnblom >> ; dev@dpdk.org >> Cc: Jerin Jacob ; Peter Nilsson >> >> Subject: Re: [PATCH] event/eth_tx: prefetch mbuf headers >> >> On 2025-05-27 12:55, Naga Harish K, S V wrote: >>> >>> >>>> -----Original Message----- >>>> From: Mattias Rönnblom >>>> Sent: Friday, March 28, 2025 11:14 AM >>>> To: dev@dpdk.org >>>> Cc: Mattias Rönnblom ; Naga Harish K, S V >>>> ; Jerin Jacob ; >>>> Mattias Rönnblom ; Peter Nilsson >>>> >>>> Subject: [PATCH] event/eth_tx: prefetch mbuf headers >>>> >>>> Prefetch mbuf headers, resulting in ~10% throughput improvement when >>>> the Ethernet RX and TX Adapters are hosted on the same core (likely >>>> ~2x in case a dedicated TX core is used). >>>> >>>> Signed-off-by: Mattias Rönnblom >>>> Tested-by: Peter Nilsson >>>> --- >>>> lib/eventdev/rte_event_eth_tx_adapter.c | 20 ++++++++++++++++++++ >>>> 1 file changed, 20 insertions(+) >>>> >>>> diff --git a/lib/eventdev/rte_event_eth_tx_adapter.c >>>> b/lib/eventdev/rte_event_eth_tx_adapter.c >>>> index 67fff8b7d6..d740ae00f9 100644 >>>> --- a/lib/eventdev/rte_event_eth_tx_adapter.c >>>> +++ b/lib/eventdev/rte_event_eth_tx_adapter.c >>>> @@ -598,6 +598,12 @@ txa_process_event_vector(struct >> txa_service_data >>>> *txa, >>>> return nb_tx; >>>> } >>>> >>>> +static inline void >>>> +txa_prefetch_mbuf(struct rte_mbuf *mbuf) { >>>> + rte_mbuf_prefetch_part1(mbuf); >>>> +} >>>> + >>>> static void >>>> txa_service_tx(struct txa_service_data *txa, struct rte_event *ev, >>>> uint32_t n) >>>> @@ -608,6 +614,20 @@ txa_service_tx(struct txa_service_data *txa, >>>> struct rte_event *ev, >>>> >>>> stats = &txa->stats; >>>> >>>> + for (i = 0; i < n; i++) { >>>> + struct rte_event *event = &ev[i]; >>>> + >>>> + if (unlikely(event->event_type & RTE_EVENT_TYPE_VECTOR)) >>> >>> >>> This gives a branch prediction advantage to non-vector events. Is that the >> intention? >>> >> >> Yes. > > I think all event-types need to be equally weighted. My ask was to remove the "unlikely" for vector events. > This is not possible. One branch will always be cheaper. If you leave out unlikely()/likely(), you leave all control to compiler heuristics. In this case, I think the resulting object code will be identical (on GCC). RTE_EVENT_TYPE_VECTOR will result in fewer events, and thus the per-event overhead is less of an issue. So if you weigh the importance of vector and non-vector use cases equally, you should optimize for the non-vector case. >> >>>> { >>>> + struct rte_event_vector *vec = event->vec; >>>> + struct rte_mbuf **mbufs = vec->mbufs; >>>> + uint32_t k; >>>> + >>>> + for (k = 0; k < vec->nb_elem; k++) >>>> + txa_prefetch_mbuf(mbufs[k]); >>>> + } else >>>> + txa_prefetch_mbuf(event->mbuf); >>>> + } >>>> + >>>> nb_tx = 0; >>>> for (i = 0; i < n; i++) { >>>> uint16_t port; >>>> -- >>>> 2.43.0 >>> >