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 E169E46BE1 for ; Tue, 22 Jul 2025 10:47:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80AD8402A5; Tue, 22 Jul 2025 10:47:15 +0200 (CEST) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mails.dpdk.org (Postfix) with ESMTP id 990D940265 for ; Tue, 22 Jul 2025 10:47:13 +0200 (CEST) Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-3138e64b42aso5365740a91.0 for ; Tue, 22 Jul 2025 01:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753174033; x=1753778833; 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=AAT2h+AHUwlhxQsQ3tYVO1h9129D3UViogKU8LjhzoM=; b=ErEod65Bz1oWKWXTW5T0strSfAW+pRGaVnhcPbrZoTDEd5L2sGeMYjtq8KGD/5SqTf ug3l/K+kTFVPHpspUg5aVJfNH8Jlyf58oLS9QnDi5F/aU/XPCf72m1krn/eWwvV+fMNF 8DuhJe3A0P1QfWyNk+E4W9ebAUPgG/Zy4sLRyrkWAztncUaQqcoI1jA7FA3xtU7xHUbC 56l7WpqusfS3PjTK+1uJCb6+wz1t6/jyogW265l3YrFZccvIlXG37aTrIvZ+2KvwQ1TX GG309veTUzXbdtA5oM5imBOSv4V0WhHfNVi900S4+5AtLe0fH+cf2IeBqfVoLkI31p22 QnrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753174033; x=1753778833; 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=AAT2h+AHUwlhxQsQ3tYVO1h9129D3UViogKU8LjhzoM=; b=dz8gn2ok2zxtv9Beuo4apWbeYxzUeAF7G3P8iMAjaKzos6RlzB5KetmbAZmG8DhQLt EL7a5Mgpe7FOUEooaztCVA0VkVhnHKxuIc7E2yvLACZJopq6AIVFRYZT3lFYw1uOvSEe MWOJhAHvYHZChkHNZuvom89wxpNiulPz6VFnRPmry7zz9RYrdfIsD47Tbrt8pqb6huGW 2rYbpk86DNMMS0Sxqy7q7eZcKHjBwPQLgGuTb3SHwDqg59lfWlsmnFIHQ8TfwLjXBXCk JSlrYcTNmNYBhGrOyFEKaElupnt/ubKlMUcgGgeHqV0CbfpGcQiSw5H3rtc1QU2Vw+tB jd0Q== X-Gm-Message-State: AOJu0YxQW0xPuKtWmiNhrGVCJuld+qCTIPLk03q68r4nzJPEDWof3wKB KXc9LP49WN2V/iSaJLeN/zO5MgCFjB9y47Cu7zE6aiLze47TIhS1d7ABUtJRqAAJ X-Gm-Gg: ASbGnctaEwxmAL//u08l8rBmqGDwBqAq8IXnlPIm7KRCdDyTpGhvFecvA/p7aoI/Dlp a9uJzU17yfX7zOR0WewexwpJsokcpNODdGYcd9osTJV/VFxtDYyMgl9htG6KNDsz84yrdzlJohH 3bz4QHW091im/1uzlYO4iDv90eHcPohQ82NCKMYlu18IMri9QqOCOLTb7kIPeqSJ0poBgfrOcmm nyM5d/zmCfyqpBQiisbGUJjjpqdutmRqB7IQU4Gh5vIZ2tSHNFu8qpgI1tKPKyt3oYzAV8R5Gup 90tcrekQUM2V3RNDLEtobWfavJfhl9FG4bhygj+nFFexkrV8DTmq5390rTBu+w+J+YtnavKrwk+ S4jiZO94YGIfGIwvkQoVRfH0FDISMwq0PXJvSqzTWcg== X-Google-Smtp-Source: AGHT+IH+pqjMZRpMSSlCZFM2Hfy62N5Dhty6XMthFb6kMAfNAxAXG2bV6IFrBGyDFL4TYTWIDq70vw== X-Received: by 2002:a17:90b:4ec8:b0:311:c970:c9ce with SMTP id 98e67ed59e1d1-31caf8f0311mr28216227a91.28.1753174032438; Tue, 22 Jul 2025 01:47:12 -0700 (PDT) Received: from [147.46.248.138] ([147.46.248.138]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-31c9f1ba792sm11514686a91.5.2025.07.22.01.47.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Jul 2025 01:47:11 -0700 (PDT) Date: Tue, 22 Jul 2025 17:46:29 +0900 From: Yoon Junghan To: Ivan Malov Cc: users@dpdk.org Message-ID: <253cf4c0-1010-4ac4-993c-6823792cbb7c@Spark> 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: 253cf4c0-1010-4ac4-993c-6823792cbb7c@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="687f4fea_41bf9ca8_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 --687f4fea_41bf9ca8_bfe4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thank you for your quick response=21 =46YI, I've already tried retrieving RX hardware timestamp without LRO, a= nd confirmed it works well. Inter arrival time of packets was about 10ns=7E= 50ns in average. I'll quickly check the references you attached. 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 > > --687f4fea_41bf9ca8_bfe4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thank you for your quick response=21
&=23160;
=46YI, I've already tried retrieving RX hardware timestamp without L= RO, and confirmed it works well. Inter arrival time of packets was about = 10ns=7E50ns in average.
&=23160;
I'll quickly check the references you attached.

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

--687f4fea_41bf9ca8_bfe4--