From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mail.toke.dk (Postfix) with ESMTPS id C0CE7A3C8DE for ; Mon, 13 Nov 2023 14:16:59 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=du/ch0FD Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 8DEEBB80DB8; Mon, 13 Nov 2023 13:16:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1556C433C8; Mon, 13 Nov 2023 13:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699881417; bh=x6T88uvFtsLiSLkHay51/pUOvdwJS3qiqD8AtZCpLNY=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=du/ch0FDLjSN2cVb/4kP7sSPE3WSKZVJi1bbcXXeWaZaQzRXnJL4ndCi19+dz6cbP 5+Z8L3TdTHw1jNwbhZYaotNBuAlT4j8rLszF3GbR029wjnXh6C3LCZo4EME/GQVvsl mZ2NG4eS0E6r3EfHEWCwZwcDMwjMyBYqVd/w3kW3pqBjkF0YFniqEzQKrZwc1WISo6 Md6cnSyfr+mnw8n+7obIQC2JcnKc7wJKsbqLmZHkoiYJdascUCKMMfqhoyjCKeo0yt Kps5mAcnd4FiUiQoksWlBLv3yzEk8bgh9GE5uOy04ChF0vl50BI7/qvMB1Fsg4EQcQ Fn/UhwDH/WtzA== Message-ID: Date: Mon, 13 Nov 2023 14:16:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Stanislav Fomichev , bpf@vger.kernel.org References: <20231102225837.1141915-1-sdf@google.com> <20231102225837.1141915-3-sdf@google.com> From: Jesper Dangaard Brouer In-Reply-To: <20231102225837.1141915-3-sdf@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: HYPP6W4AF6AK3HRDJSBT3J5O4NNYSQFI X-Message-ID-Hash: HYPP6W4AF6AK3HRDJSBT3J5O4NNYSQFI X-MailFrom: hawk@kernel.org 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: hawk@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, magnus.karlsson@intel.com, bjorn@kernel.org, maciej.fijalkowski@intel.com, yoong.siang.song@intel.com, netdev@vger.kernel.org, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v5 02/13] xsk: Add TX timestamp and TX checksum offload support List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 11/2/23 23:58, Stanislav Fomichev wrote: > diff --git a/include/uapi/linux/if_xdp.h b/include/uapi/linux/if_xdp.h > index 2ecf79282c26..b0ee7ad19b51 100644 > --- a/include/uapi/linux/if_xdp.h > +++ b/include/uapi/linux/if_xdp.h > @@ -106,6 +106,41 @@ struct xdp_options { > #define XSK_UNALIGNED_BUF_ADDR_MASK \ > ((1ULL << XSK_UNALIGNED_BUF_OFFSET_SHIFT) - 1) > > +/* Request transmit timestamp. Upon completion, put it into tx_timestamp > + * field of struct xsk_tx_metadata. > + */ > +#define XDP_TXMD_FLAGS_TIMESTAMP (1 << 0) > + > +/* Request transmit checksum offload. Checksum start position and offset > + * are communicated via csum_start and csum_offset fields of struct > + * xsk_tx_metadata. > + */ > +#define XDP_TXMD_FLAGS_CHECKSUM (1 << 1) > + > +/* AF_XDP offloads request. 'request' union member is consumed by the driver > + * when the packet is being transmitted. 'completion' union member is > + * filled by the driver when the transmit completion arrives. > + */ > +struct xsk_tx_metadata { > + union { > + struct { > + __u32 flags; > + > + /* XDP_TXMD_FLAGS_CHECKSUM */ > + > + /* Offset from desc->addr where checksumming should start. */ > + __u16 csum_start; > + /* Offset from csum_start where checksum should be stored. */ > + __u16 csum_offset; > + } request; > + > + struct { > + /* XDP_TXMD_FLAGS_TIMESTAMP */ > + __u64 tx_timestamp; > + } completion; > + }; > +}; This looks wrong to me. It looks like member @flags is not avail at completion time. At completion time, I assume we also want to know if someone requested to get the timestamp for this packet (else we could read garbage). Another thing (I've raised this before): It would be really practical to store an u64 opaque value at TX and then read it at Completion time. One use-case is a forwarding application storing HW RX-time and comparing this to TX completion time to deduce the time spend processing the packet. --Jesper