From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by mail.toke.dk (Postfix) with ESMTPS id 21E89A35635 for ; Tue, 24 Oct 2023 18:41:52 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=m+YhmY1a Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-564af0ac494so2962327a12.0 for ; Tue, 24 Oct 2023 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698165709; x=1698770509; darn=xdp-project.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F9cI2QYCQEc0Q/Z2mJbULzav03v+BRSAlGepCbIXf4g=; b=m+YhmY1a5Zax3R7bYuX9GgABPQhCvMB50AMlAtXjdZFd1+SeBca0Mi2Espv5swwp5B 8+MYfpiABI7gZ4wziAW5kDh/R+CWtrBh+9IiVOHuz1ipjqx8eMiKLbt14sLul2sgXeVS QONOc/Vaafol6550rHaMC0pgH3gCN/dsV6vI680ZALS8C7UFRIHpgOM5zj6dpBQRZ7bP FMPKTfgMSqTWhNavaw5ZjoxK0qY3pMT0+oQsVwuOIrjhykGerHWP32cxP2BmFeCQi9BN vQlgHlL937foCTvrhpe3gEN+jtPPwrbjsuBzbmJoytgXYGnnrxYlwyC0fUrxyLvCoJ4A l4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698165709; x=1698770509; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F9cI2QYCQEc0Q/Z2mJbULzav03v+BRSAlGepCbIXf4g=; b=UGqGnIaPB6JJLCPqFXymLwXMoen2UolSJlgmZkITLD6jVDBagg1kDF3I+2SsI5WQr7 z1i88h8wJ4yGUm45jiYoakDzHr2umwvIrb7iAtyVwZ/sirccMGqZ8DD7T8BsaH511ODF XK9ZCqTjUFBK6XAaUwnjMOq5OLZNJr1jkqgqRXNpRortdpOCdtn2f+0sMCjR0bsez0oz tGs1UrkGkPC2vhZ0HcM5RoiIlhUEj05yI7BIr+/mzAjcgYoBapy2aXbiVxXBT+sGBKhQ rb1tukLdJJCcgJehurtbc+M0yEorA48C9KqLEs8/ayBDRLaNsGutzk2nApuyU+uos4Xy MaoA== X-Gm-Message-State: AOJu0YzSBJAENlmtCrVoA/n/M3YESFv7g5ZE86lnNRKnlpYtgM/AHMVk SF/2shYdXJpk2zP8wSn5QUaAey2iayN1COGuDDh0xg== X-Google-Smtp-Source: AGHT+IGAdVWT4mftFEAGQrXm3G8HV7gIjum7jCbwbb9KaUknUgk1WfDEZHCMV8V8bp+yGQa2u32B3NoAvqDI+8P/hfU= X-Received: by 2002:a17:90a:4f45:b0:27e:3880:d03d with SMTP id w5-20020a17090a4f4500b0027e3880d03dmr6113296pjl.7.1698165708830; Tue, 24 Oct 2023 09:41:48 -0700 (PDT) MIME-Version: 1.0 References: <20231019174944.3376335-1-sdf@google.com> <20231019174944.3376335-11-sdf@google.com> In-Reply-To: From: Stanislav Fomichev Date: Tue, 24 Oct 2023 09:41:36 -0700 Message-ID: To: "Song, Yoong Siang" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: WZO25OOE6DBLI53SZSHE5P6HRN6WOQAA X-Message-ID-Hash: WZO25OOE6DBLI53SZSHE5P6HRN6WOQAA X-MailFrom: sdf@google.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "bpf@vger.kernel.org" , "ast@kernel.org" , "daniel@iogearbox.net" , "andrii@kernel.org" , "martin.lau@linux.dev" , "song@kernel.org" , "yhs@fb.com" , "john.fastabend@gmail.com" , "kpsingh@kernel.org" , "haoluo@google.com" , "jolsa@kernel.org" , "kuba@kernel.org" , "toke@kernel.org" , "willemb@google.com" , "dsahern@kernel.org" , "Karlsson, Magnus" , "bjorn@kernel.org" , "Fijalkowski, Maciej" , "hawk@kernel.org" , "netdev@vger.kernel.org" , "xdp-hints@xdp-project.net" X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v4 10/11] selftests/bpf: Add TX side to xdp_hw_metadata List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, Oct 23, 2023 at 7:19=E2=80=AFPM Song, Yoong Siang wrote: > > On Friday, October 20, 2023 1:50 AM Stanislav Fomichev w= rote: > >When we get a packet on port 9091, we swap src/dst and send it out. > >At this point we also request the timestamp and checksum offloads. > > > >Checksum offload is verified by looking at the tcpdump on the other side= . > >The tool prints pseudo-header csum and the final one it expects. > >The final checksum actually matches the incoming packets checksum > >because we only flip the src/dst and don't change the payload. > > > >Some other related changes: > >- switched to zerocopy mode by default; new flag can be used to force > > old behavior > >- request fixed tx_metadata_len headroom > >- some other small fixes (umem size, fill idx+i, etc) > > > >mvbz3:~# ./xdp_hw_metadata eth3 > >... > >xsk_ring_cons__peek: 1 > >0x19546f8: rx_desc[0]->addr=3D80100 addr=3D80100 comp_addr=3D80100 > >rx_hash: 0x80B7EA8B with RSS type:0x2A > >rx_timestamp: 1697580171852147395 (sec:1697580171.8521) > >HW RX-time: 1697580171852147395 (sec:1697580171.8521), delta to User R= X-time sec:0.2797 (279673.082 usec) > >XDP RX-time: 1697580172131699047 (sec:1697580172.1317), delta to User = RX-time sec:0.0001 (121.430 usec) > >0x19546f8: ping-pong with csum=3D3b8e (want d862) csum_start=3D54 csum_o= ffset=3D6 > >0x19546f8: complete tx idx=3D0 addr=3D8 > >tx_timestamp: 1697580172056756493 (sec:1697580172.0568) > > Hi Stanislav, > > rx_timestamp is duplicating HW RX-time while tx_timestamp is duplicating = HW TX-complete-time, > so, I think can remove printing of rx_timestamp and tx_timestamp to avoid= confusion. That's fair, I think I'll do the following: if (meta->rx_timestamp) { /* print all those reference points */ } else { printf("No rx_timestamp\n"); } And the same for tx. So at least the users get a signal that the timestamps weren't set. > >HW TX-complete-time: 1697580172056756493 (sec:1697580172.0568), delta = to User TX-complete-time sec:0.0852 (85175.537 usec) > >XDP RX-time: 1697580172131699047 (sec:1697580172.1317), delta to User = TX-complete-time sec:0.0102 (10232.983 usec) > >HW RX-time: 1697580171852147395 (sec:1697580171.8521), delta to HW TX-= complete-time sec:0.2046 (204609.098 usec) > >0x19546f8: complete rx idx=3D128 addr=3D80100 > > > >mvbz4:~# nc -Nu -q1 ${MVBZ3_LINK_LOCAL_IP}%eth3 9091 > > > >mvbz4:~# tcpdump -vvx -i eth3 udp > > tcpdump: listening on eth3, link-type EN10MB (Ethernet), snapsho= t length 262144 > >bytes > >12:26:09.301074 IP6 (flowlabel 0x35fa5, hlim 127, next-header UDP (17) p= ayload > >length: 11) fe80::1270:fdff:fe48:1087.55807 > fe80::1270:fdff:fe48:1077.= 9091: [bad > >udp cksum 0x3b8e -> 0xde7e!] UDP, length 3 > > 0x0000: 6003 5fa5 000b 117f fe80 0000 0000 0000 > > 0x0010: 1270 fdff fe48 1087 fe80 0000 0000 0000 > > 0x0020: 1270 fdff fe48 1077 d9ff 2383 000b 3b8e > > 0x0030: 7864 70 > >12:26:09.301976 IP6 (flowlabel 0x35fa5, hlim 127, next-header UDP (17) p= ayload > >length: 11) fe80::1270:fdff:fe48:1077.9091 > fe80::1270:fdff:fe48:1087.5= 5807: [udp > >sum ok] UDP, length 3 > > 0x0000: 6003 5fa5 000b 117f fe80 0000 0000 0000 > > 0x0010: 1270 fdff fe48 1077 fe80 0000 0000 0000 > > 0x0020: 1270 fdff fe48 1087 2383 d9ff 000b de7e > > 0x0030: 7864 70 > > > >This reverts commit c3c9abc1d0c989e0be21d78cccd99076cc94ec44. > > It didn't looked like this patch is reverting something. > If this is not a mistake, can you add the commit title behind the ID? Ah, that's a leftover from my rebasing and reshuffling, will drop, thanks!