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 AAE9446BF1 for ; Wed, 23 Jul 2025 14:44:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C452402E7; Wed, 23 Jul 2025 14:44:26 +0200 (CEST) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by mails.dpdk.org (Postfix) with ESMTP id 5464F402E1 for ; Wed, 23 Jul 2025 14:44:25 +0200 (CEST) Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-7494999de5cso4488589b3a.3 for ; Wed, 23 Jul 2025 05:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753274664; x=1753879464; darn=dpdk.org; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=QeWJqjIw7jfB7Sun6em9FOhaCaADathd73bm9X626k0=; b=ktt9+nREcvl089+7GQVu3b69zOKcYOpw3Qp7pehgD2gZGwlGOHU8MrslvwnU+kQoIX wntLfU5TIiT8q2qTPb3ZEjfX/qjl5/rNXgqr//EC0n7HbSPgxEmhlO1fKf3R6F7afza7 X5gOL4CIC6RldXXKnrstT1P+659Q9QiaPWLw6ImE9kL0Mrg/603uUXoxTVT/t59DjZF/ Syu25bMHHd/IiZXheC/Dq4J1POOignXTQ/KskL2iD2t3+OZJFy9iIj126ij8mp62Rvpg YcDuCooZyE6JFsuH8Hr04mKJa8Khmc1qes5Z/47jZz2vDuthNvaJ7DoFmRY5a33ivxId /FDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753274664; x=1753879464; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QeWJqjIw7jfB7Sun6em9FOhaCaADathd73bm9X626k0=; b=W75B/lbi0hbXZzMkddnRE94JEP/tGuClh5/JlHC0E5KKQTgwkuOyMIcpTxZXmUGJJy f65p3/TSoXPWcN3alhWhNAf/xmspmS1d/pGOB5Ddcpkqwd7AVuBwSBO8/fhayhJtp1Yl bmNr9YhOCIDyhTaQgAez38wQXN7qx0XutW6gI2oC9+bExpWs1GKw6ZuabzZQy72LHoPe h0Djywt1V9dQdLuL1q4XsXchNHQL5W/0jZqgW4yDSXHhzZ1GfWpHWJplh4tIqB6AyVEC iy19IbQ3zJ1KeBf+Iyg73I04w24Q6AUot3k18IVXKaoE63yeP2ZpsrgOhimHLub13vf4 oRSg== X-Gm-Message-State: AOJu0YxKJgFjdbR07TObZFc88QtQW7QuBUM9/qsc0Q2CCB721IYnqi8T gXIWJoFaFNz2m28tNIDwKG3LWP2AexZGPkW2RtMUcio3rLmEUwd1SCgZNsdIhHBOuO0= X-Gm-Gg: ASbGncsfZrEOi11UHoycxLbBH2U4N9nWF8ZnH/vycf/lu05SBzlnWYWZJUX1IA4/HfI Ht/FnS/echaI4XDzmSV6vJlBRA851npBK/cRZK7LLc4DrBQZqZNnfFM8gySz0iNSTaXq4sma3pp Wjb6AX9m3GN3uMejvcq2v9Tpl+9bgZVgPygmkyrXYTLsZL85cJeZW5B2WyzJcaZI9b2NBoJQbnp oyrUz/gjINCLqRKR4sq8CEw+CKFcOveWb7hlwqRUDR0enddM83tAJzZYztkgoGzmDTGgzrjJfVC mHVmjI5l46opjU1o8a9w0453MhXh+dqqG2QVpgXufJjRuKL3qLTlRT/MS2+8ZhBUnMRopF2okGT oE19bz9JEJrkqOwI9OyrcXBvg0vpbAH1Cu/MZxSyZvqdq6uUBX02T X-Google-Smtp-Source: AGHT+IFFnz6wIe7l8wEA9MS0YheaYRV1+/HJo0TOlhNf7lUcifAAI6dDsARS3Svd2bJg+LueV+XJDg== X-Received: by 2002:a05:6a20:7348:b0:220:9d84:1cf6 with SMTP id adf61e73a8af0-23d490ea313mr5247322637.22.1753274664231; Wed, 23 Jul 2025 05:44:24 -0700 (PDT) Received: from [147.46.248.138] ([147.46.248.138]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-759c8acb61csm9736386b3a.64.2025.07.23.05.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jul 2025 05:44:22 -0700 (PDT) Date: Wed, 23 Jul 2025 21:43:38 +0900 From: Yoon Junghan To: Ivan Malov Cc: users@dpdk.org Message-ID: In-Reply-To: <3f7df93b-ee00-bcdb-337c-8faa7bd73f6c@arknetworks.am> References: <3f7df93b-ee00-bcdb-337c-8faa7bd73f6c@arknetworks.am> Subject: Re: HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11) X-Readdle-Message-ID: a48c2e1b-d8c6-4012-93d1-22bee864637f@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6880d902_f8ad100a_bfe4" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --6880d902_f8ad100a_bfe4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, As advised, I tested hardware timestamps with LRO enabled on our ConnectX= -7 NICs. However, the timestamps of LROed packets still show inconsistent= and abnormally large gaps from normal packets. Interestingly, I found this issue does not appear on all CX-7 NICs. Even = with identical DPDK code, firmware version (28.43.2566), and hardware mod= els from the same manufacturer, only specific NICs exhibit this inconsist= ency. I have confirmed that: =E2=80=A2 All NICs use the same driver and firmware version. =E2=80=A2 All NICs are of the same model (MCX75310AAS-NEA=5FAx). =E2=80=A2 The issue occurs only when LRO is enabled together with RX hard= ware timestamping. =E2=80=A2 Disabling LRO eliminates the issue. I would appreciate any insight into how this behavior can occur on only s= ome ports despite same software and hardware setup. Below is my code snippet. =60=60=60c /*-----------------------------------------------------------------------= -----*/ static inline int is=5Ftimestamp=5Fenabled(struct rte=5Fmbuf *mbuf) =7B =C2=A0 =C2=A0static uint64=5Ft timestamp=5Frx=5Fdynflag =3D 0; =C2=A0 =C2=A0int timestamp=5Frx=5Fdynflag=5Foffset; =C2=A0 =C2=A0if (=21timestamp=5Frx=5Fdynflag) =C2=A0 =C2=A0=7B =C2=A0 =C2=A0 =C2=A0 =C2=A0timestamp=5Frx=5Fdynflag=5Foffset =3D =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rte=5Fmbuf=5Fdynflag=5Flookup(RT= E=5FMBU=46=5FDYN=46LAG=5FRX=5FTIMESTAMP=5FNAME, NULL); =C2=A0 =C2=A0 =C2=A0 =C2=A0if (timestamp=5Frx=5Fdynflag=5Foffset < 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0=7B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0 =C2=A0 =C2=A0 =C2=A0timestamp=5Frx=5Fdynflag =3D RTE=5FBIT64(times= tamp=5Frx=5Fdynflag=5Foffset); =C2=A0 =C2=A0=7D =C2=A0 =C2=A0return mbuf->ol=5Fflags & timestamp=5Frx=5Fdynflag; =7D /*-----------------------------------------------------------------------= -----*/ static inline rte=5Fmbuf=5Ftimestamp=5Ft * get=5Ftimestamp(struct rte=5Fmbuf *mbuf) =7B =C2=A0 =C2=A0static int timestamp=5Fdynfield=5Foffset =3D -1; =C2=A0 =C2=A0if (timestamp=5Fdynfield=5Foffset < 0) =C2=A0 =C2=A0=7B =C2=A0 =C2=A0 =C2=A0 =C2=A0timestamp=5Fdynfield=5Foffset =3D =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rte=5Fmbuf=5Fdynfield=5Flookup(R= TE=5FMBU=46=5FDYN=46IELD=5FTIMESTAMP=5FNAME, NULL); =C2=A0 =C2=A0 =C2=A0 =C2=A0if (timestamp=5Fdynfield=5Foffset < 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0=7B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0 =C2=A0=7D =C2=A0 =C2=A0return RTE=5FMBU=46=5FDYN=46IELD(mbuf, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0timestamp=5Fdynfield=5Foffset, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rte=5Fmbuf=5Ftimestamp=5Ft *); =7D /*-----------------------------------------------------------------------= -----*/ static inline rte=5Fmbuf=5Ftimestamp=5Ft * get=5Frx=5Fhw=5Ftimestamp(struct rte=5Fmbuf *pkt) =7B =C2=A0 =C2=A0if (=21is=5Ftimestamp=5Fenabled(pkt)) =C2=A0 =C2=A0=7B =C2=A0 =C2=A0 =C2=A0 =C2=A0printf(=22rx=5Fhw=5Ftimestamp not enabled in m= buf=21=5Cn=22); =C2=A0 =C2=A0 =C2=A0 =C2=A0return NULL; =C2=A0 =C2=A0=7D =C2=A0 =C2=A0return get=5Ftimestamp(pkt); =7D =60=60=60 My DPDK application prints logs as below. =60=60=60c =C2=A0 =C2=A0/* parse HW timestamp */ =C2=A0 =C2=A0rte=5Fmbuf=5Ftimestamp=5Ft *rx=5Ftimestamp =3D get=5Frx=5Fhw= =5Ftimestamp(pkt); =C2=A0 =C2=A0printf(=22=5Bport %d=5D RX HW timestamp: %=23016lx %s=5Cn=22= , =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pctx->port=5Fid, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *rx=5Ftimestamp, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pkt->ol=5Fflags & PKT=5FRX=5FLRO =3F =22= (LROed)=22 : =22(not LROed)=22); =60=60=60 Below are observations from two CX-7 ports under identical conditions. Normal NIC (port 0): =5Bport 0=5D RX HW timestamp: 0x00007dcd2d185b (LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd2d1911 (LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd2d19c9 (LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd2d37ca (LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd2d4cb3 (not LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd2d4cb3 (not LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd30e019 (not LROed) =5Bport 0=5D RX HW timestamp: 0x00007dcd3280bb (not LROed) Erroneous NIC (port 1): Below is erroneous NIC's timestamp. =5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed) =5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed) =5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed) =5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed) =5Bport 1=5D RX HW timestamp: 0x000080691b7557 (not LROed) =5Bport 1=5D RX HW timestamp: 0x000080691e2311 (not LROed) =5Bport 1=5D RX HW timestamp: 0x00008069357553 (not LROed) =5Bport 1=5D RX HW timestamp: 0x0000806936e8c1 (not LROed) As shown above, non-LRO packets consistently have normal hardware timesta= mps on both NICs. However, on port 1, all LROed packets return a fixed, i= nvalid timestamp (0x3e6eef91bc19f0fd), which is clearly inconsistent. I have also confirmed that other dynfields (rather than dynfield=5B1=5D a= nd dynfield=5B2=5D) are unused. Sincerely, Junghan Yoon On Jul 22, 2025, 5:31 PM +0900, Ivan Malov ,= wrote: > Hello, > > On Tue, 22 Jul 2025, Yoon Junghan wrote: > > > Hello, > > > > I'm currently using DPDK 20.11 with a ConnectX-7 NIC, and I'm trying = to retrieve RX hardware timestamps using =60rte=5Fmbuf=5Fdyn=5Frx=5Ftimes= tamp=5Fregister()=60. > > Does the application invoke 'rte=5Fmbuf=5Fdyn=5Frx=5Ftimestamp=5Fregist= er' on its own=3F If > yes, consider to replace this with invocations of APIs =5B1=5D (with fi= eld name =5B2=5D) > and =5B3=5D (with flag name =5B4=5D). =46or an example, please refer to= =5B5=5D and =5B6=5D. > > This is because, as per =5B7=5D, the driver in question might 'register= ' the field > and the flag on its own, in response to 'DEV=5FRX=5FO=46=46LOAD=5FTIMES= TAMP' request, so, > the user application should look up the field/flag, not 'register' it a= fresh. > > If this does not help, then consider to clarify whether the timestamps = are > accurate (and whether the flag is seen in the mbufs) when LRO is not en= abled. > > =5B1=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html= =23a6adf9b352a83e7d521fd6aa04e305b1c > =5B2=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html= =23a5159b2d34fa801d171ed0ccce451121b > =5B3=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html= =23a89d835027034f76a27eb2afe7987ae35 > =5B4=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html= =23a831d7066c7193788351797a65186848a > =5B5=5D https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b965974= 69b7f6e6207/app/test-pmd/util.c=23L44 > =5B6=5D https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b965974= 69b7f6e6207/app/test-pmd/util.c=23L60 > =5B7=5D https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b965974= 69b7f6e6207/drivers/net/mlx5/mlx5=5Frxq.c=23L1743 > > Thank you. > > > > > When LRO is enabled, I notice that LROed mbufs seem to share identica= l timestamp values, and the timestamps are unexpectedly large or inconsis= tent. This raises the question of whether > > LRO is interfering with the correctness of the RX HW timestamps. > > > > I=E2=80=99d appreciate any clarification on whether HW RX timestampin= g is reliable when LRO is enabled on this platform, or if LRO should be j= ust disabled for accurate per-packet timestamping. > > > > > > Sincerely, > > Junghan Yoon > > --6880d902_f8ad100a_bfe4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello,
As advised, I tested hardware timestamps with LRO enabled on our Con= nectX-7 NICs. However, the timestamps of LROed packets still show inconsi= stent and abnormally large gaps from normal packets.
&=23160;
Interestingly, I found this issue does not appear on all CX-7 NICs. = Even with identical DPDK code, firmware version (28.43.2566), and hardwar= e models from the same manufacturer, only specific NICs exhibit this inco= nsistency.
I have confirmed that:
  • All NICs use the same driver and firmware version.
  • All NICs are of the same model (MCX75310AAS-NEA=5FAx).
  • The issue occurs only when LRO is enabled together with RX hardware t= imestamping.
  • Disabling LRO eliminates the issue.
I would appreciate any insight into how this behavior can occur on o= nly some ports despite same software and hardware setup.
&=23160;
Below is my code snippet.
&=23160;
=60=60=60c
/*-----------------------------------------------------------------------= -----*/
static inline int
is=5Ftimestamp=5Fenabled(struct rte=5Fmbuf *mbuf)
=7B
&=23160; &=23160;static uint64=5Ft timestamp=5Frx=5Fdynflag =3D 0;
&=23160; &=23160;int timestamp=5Frx=5Fdynflag=5Foffset;
&=23160;
&=23160; &=23160;if (=21timestamp=5Frx=5Fdynflag)
&=23160; &=23160;=7B
&=23160; &=23160; &=23160; &=23160;timestamp=5Frx=5Fdynflag=5Foffset =3D<= br /> &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;rte=5Fmbuf=5Fdynflag= =5Flookup(RTE=5FMBU=46=5FDYN=46LAG=5FRX=5FTIMESTAMP=5FNAME, NULL);
&=23160; &=23160; &=23160; &=23160;if (timestamp=5Frx=5Fdynflag=5Foffset = < 0)
&=23160; &=23160; &=23160; &=23160;=7B
&=23160; &=23160; &=23160; &=23160; &=23160; &=23160;return 0;
&=23160; &=23160; &=23160; &=23160;=7D
&=23160; &=23160; &=23160; &=23160;timestamp=5Frx=5Fdynflag =3D RTE=5FBIT= 64(timestamp=5Frx=5Fdynflag=5Foffset);
&=23160; &=23160;=7D
&=23160;
&=23160; &=23160;return mbuf->ol=5Fflags & timestamp=5Frx=5Fd= ynflag;
=7D
/*-----------------------------------------------------------------------= -----*/
static inline rte=5Fmbuf=5Ftimestamp=5Ft *
get=5Ftimestamp(struct rte=5Fmbuf *mbuf)
=7B
&=23160; &=23160;static int timestamp=5Fdynfield=5Foffset =3D -1;
&=23160;
&=23160; &=23160;if (timestamp=5Fdynfield=5Foffset < 0)
&=23160; &=23160;=7B
&=23160; &=23160; &=23160; &=23160;timestamp=5Fdynfield=5Foffset =3D
&=23160; &=23160; &=23160; &=23160; &=23160; &=23160;rte=5Fmbuf=5Fdynfiel= d=5Flookup(RTE=5FMBU=46=5FDYN=46IELD=5FTIMESTAMP=5FNAME, NULL);
&=23160; &=23160; &=23160; &=23160;if (timestamp=5Fdynfield=5Foffset <= 0)
&=23160; &=23160; &=23160; &=23160;=7B
&=23160; &=23160; &=23160; &=23160; &=23160; &=23160;return 0;
&=23160; &=23160; &=23160; &=23160;=7D
&=23160; &=23160;=7D
&=23160;
&=23160; &=23160;return RTE=5FMBU=46=5FDYN=46IELD(mbuf,
&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &= =23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;timestamp=5F= dynfield=5Foffset,
&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &= =23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;rte=5Fmbuf=5F= timestamp=5Ft *);
=7D
/*-----------------------------------------------------------------------= -----*/
static inline rte=5Fmbuf=5Ftimestamp=5Ft *
get=5Frx=5Fhw=5Ftimestamp(struct rte=5Fmbuf *pkt)
=7B
&=23160; &=23160;if (=21is=5Ftimestamp=5Fenabled(pkt))
&=23160; &=23160;=7B
&=23160; &=23160; &=23160; &=23160;printf(=22rx=5Fhw=5Ftimestamp not enab= led in mbuf=21=5Cn=22);
&=23160; &=23160; &=23160; &=23160;return NULL;
&=23160; &=23160;=7D
&=23160;
&=23160; &=23160;return get=5Ftimestamp(pkt);
=7D
=60=60=60
&=23160;
My DPDK application prints logs as below.
&=23160;
=60=60=60c
&=23160; &=23160;/* parse HW timestamp */
&=23160; &=23160;rte=5Fmbuf=5Ftimestamp=5Ft *rx=5Ftimestamp =3D get=5Frx=5F= hw=5Ftimestamp(pkt);
&=23160; &=23160;printf(=22=5Bport %d=5D RX HW timestamp: %=23016lx %s=5C= n=22,
&=23160; &=23160; &=23160; &=23160; &=23160; pctx->port=5Fid,
&=23160; &=23160; &=23160; &=23160; &=23160; *rx=5Ftimestamp,
&=23160; &=23160; &=23160; &=23160; &=23160; pkt->ol=5Fflags & PKT= =5FRX=5FLRO =3F =22(LROed)=22 : =22(not LROed)=22);
=60=60=60
&=23160;
Below are observations from two CX-7 ports under identical condition= s.
&=23160;
Normal NIC (port 0):
=5Bport 0=5D RX HW timestamp: 0x00007dcd2d185b (LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd2d1911 (LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd2d19c9 (LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd2d37ca (LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd2d4cb3 (not LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd2d4cb3 (not LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd30e019 (not LROed)
=5Bport 0=5D RX HW timestamp: 0x00007dcd3280bb (not LROed)
&=23160;
Erroneous NIC (port 1):
Below is erroneous NIC's timestamp.
=5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed)
=5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed)
=5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed)
=5Bport 1=5D RX HW timestamp: 0x3e6eef91bc19f0fd (LROed)
=5Bport 1=5D RX HW timestamp: 0x000080691b7557 (not LROed)
=5Bport 1=5D RX HW timestamp: 0x000080691e2311 (not LROed)
=5Bport 1=5D RX HW timestamp: 0x00008069357553 (not LROed)
=5Bport 1=5D RX HW timestamp: 0x0000806936e8c1 (not LROed)

As shown above, non-LRO packets consistently have normal hardware timesta= mps on both NICs. However, on port 1, all LROed packets return a fixed, i= nvalid timestamp (0x3e6eef91bc19f0fd), which is clearly inco= nsistent.
I have also confirmed that other dynfields (rather than dynfield=5B1= =5D and dynfield=5B2=5D) are unused.
&=23160;

Sincerely,
Junghan Yoon
On Jul 22, 2025, 5:31 PM +0900, Iva= n Malov <ivan.malov=40arknetworks.am>, wrote:
Hello,

On Tue, 22 Jul 2025, Yoon Junghan wrote:

Hello,
&=23160;
I'm currently using DPDK 20.11 with a ConnectX-7 NIC, and I'm trying to r= etrieve RX hardware timestamps using =60rte=5Fmbuf=5Fdyn=5Frx=5Ftimestamp= =5Fregister()=60.

Does the application invoke 'rte=5Fmbuf=5Fdyn=5Frx=5Ftimestamp=5Fregister= ' on its own=3F If
yes, consider to replace this with invocations of APIs =5B1=5D (with fiel= d name =5B2=5D)
and =5B3=5D (with flag name =5B4=5D). =46or an example, please refer to =5B= 5=5D and =5B6=5D.

This is because, as per =5B7=5D, the driver in question might 'register' = the field
and the flag on its own, in response to 'DEV=5FRX=5FO=46=46LOAD=5FTIMESTA= MP' request, so,
the user application should look up the field/flag, not 'register' it afr= esh.

If this does not help, then consider to clarify whether the timestamps ar= e
accurate (and whether the flag is seen in the mbufs) when LRO is not enab= led.

=5B1=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html=23= a6adf9b352a83e7d521fd6aa04e305b1c
=5B2=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html=23= a5159b2d34fa801d171ed0ccce451121b
=5B3=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html=23= a89d835027034f76a27eb2afe7987ae35
=5B4=5D https://doc.dpdk.org/api-20.11/rte=5F=5Fmbuf=5F=5Fdyn=5F8h.html=23= a831d7066c7193788351797a65186848a
=5B5=5D https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469= b7f6e6207/app/test-pmd/util.c=23L44
=5B6=5D https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469= b7f6e6207/app/test-pmd/util.c=23L60
=5B7=5D https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469= b7f6e6207/drivers/net/mlx5/mlx5=5Frxq.c=23L1743

Thank you.

&=23160;
When LRO is enabled, I notice that LROed mbufs seem to share identical ti= mestamp values, and the timestamps are unexpectedly large or inconsistent= . This raises the question of whether
LRO is interfering with the correctness of the RX HW timestamps.
&=23160;
I=E2=80=99d appreciate any clarification on whether HW RX timestamping is= reliable when LRO is enabled on this platform, or if LRO should be just = disabled for accurate per-packet timestamping.
&=23160;

Sincerely,
Junghan Yoon

--6880d902_f8ad100a_bfe4--