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 B426D46BDD for ; Tue, 22 Jul 2025 09:22:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 44D32402A5; Tue, 22 Jul 2025 09:22:30 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 2AF5640265 for ; Tue, 22 Jul 2025 09:22:29 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-23dea2e01e4so60421145ad.1 for ; Tue, 22 Jul 2025 00:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753168947; x=1753773747; darn=dpdk.org; h=mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=KNkfKL07tPM7RrO5DJchJCLFBPqq4NX+6NXZ74db9qw=; b=T9iZsL7NTD6aoQDQ2kZ+EfIIGtgJnkBV1mfqVU4sIvPvItSg/LRAnhr1Uc0IgU6v9d Hg6UhC5bknsO22W3DJp7EGfmXuBU/q/wIFHSi9Uo2MQ//z3Nf/t1Gy8QJIIXTATycoka UP1E15lPTDs0BMbDklYEG0PfdYPrTZHFA32GIamLgCYADuyE+CSoDNCZpFkgFEJnM3tG MokpfeQY0DyQE0kwld2AHdyoZNcpC1z/KFg9LEgtwjKd62pQEaeY8BGbKWRkjq1T8P+B 1jRIJT4+ZNpjreAAH9xMDd1nYcANOPqQG2ZupS1fgAZdxX2Zrn+utqGpcdtiYDMpBJqS niSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753168947; x=1753773747; h=mime-version:subject:message-id:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KNkfKL07tPM7RrO5DJchJCLFBPqq4NX+6NXZ74db9qw=; b=PTV7BVzWIWrQw5uS/xHL7F+TunIGMe2BLbBIO8c1+wcaDubQIY747zkMA4Z3Ye1mLP XFxAbLu0YGEKg1U9xcNyf/i1pvV8Rs4ejb0lwcKlHr4UweIhdutUxxjoOINHzIcwPxrq lKjLMyweroWhjeLbQqvCIJLGKAptJ8DGw3XG33zRe3CUQSeiJW2sK4GOtm02ZOYd0uXa ico+BdS1yzfhVmG5YwV4BPOS3+vBMc3FshoOG+7Z2TGt4tR+7f12gAoKA/xEF6PYmfaC tWiGEw+N7Io+j+3UaB7JXLF96rTl/DplIBCboms/BtbT1b7fZXjofuqEco/chb464C4+ Q3yw== X-Gm-Message-State: AOJu0YxoNdUTMJqKbD2PAGYkdrwNud1VQMbuSkgtZ9zM9oK7gYZZ4Ot/ Yzv8BaODsp3sAOQ4w7jEVrE82Gygx9xMhkWQN3F6FAPsODpeBUnXZOI7JwnY/sb+ X-Gm-Gg: ASbGncutITEEkT5X8HfYDnx7ekvDWHyWnKclkTpAc4xmYn+27pDifgZlwW8r/hOOE5Q lBHFdtApp8J/RXo9Z5tjK0YL21yOuS5FZO9ueRFL1ZD/wsO6Drv0ulR4vgM8XBrufaZwq96ppR7 HG20BZt3GPwHVqjoggaIQf+i0y/aOsNuENILpkKDNhPCNmtrgtUY9irrhh29y49+vboQzjJuqP6 NP163hBU3KYe9dM8whikCQrgOCMfNMAng6607r0cxEEXO2tF5AblcxNPfcFt1ns8glCXWNP6g3s HVdk5OLkpxQyyLoO/rt6DC/E1mQPRV1S1HNOqZGjUqN/L+0k5PgfOO4swxTaS0Y4S0+lzj7IZM9 5CZ/Xlzt59mepsjX4YMjnDWBQAiZp53gPcs59AqXvNg== X-Google-Smtp-Source: AGHT+IEuskuyOLmPeAhMWvDDIBI6NVyB5iA2naLaqJJxIhi1OxUoJQ7wPnFaN8+28FvGx6BzsQWL5Q== X-Received: by 2002:a17:903:228a:b0:235:e942:cb9c with SMTP id d9443c01a7336-23e2566aa35mr352772175ad.5.1753168947445; Tue, 22 Jul 2025 00:22:27 -0700 (PDT) Received: from [147.46.248.138] ([147.46.248.138]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-23e3c3b2c4esm69293025ad.189.2025.07.22.00.22.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Jul 2025 00:22:26 -0700 (PDT) Date: Tue, 22 Jul 2025 16:21:44 +0900 From: Yoon Junghan To: users@dpdk.org Message-ID: Subject: HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11) X-Readdle-Message-ID: b05b756f-d8ea-4b2b-a8bf-ea309efeff21@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="687f3c0d_b4b68e75_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 --687f3c0d_b4b68e75_bfe4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, 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. 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 correct= ness of the RX HW timestamps. 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. Sincerely, Junghan Yoon --687f3c0d_b4b68e75_bfe4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello,
&=23160;
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=5Ftime= stamp=5Fregister()=60.
&=23160;
When LRO is enabled, I notice that LROed mbufs seem to share identic= al timestamp values, and the timestamps are unexpectedly large or inconsi= stent. This raises the question of whether LRO is interfering with the co= rrectness of the RX HW timestamps.
&=23160;
I=E2=80=99d appreciate any clarification on whether HW RX timestampi= ng 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
--687f3c0d_b4b68e75_bfe4--