From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by mail.toke.dk (Postfix) with ESMTPS id 46D31A1D0F7 for ; Sat, 29 Jul 2023 18:15:30 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=dEGwFuN2 Received: by mail-qk1-x72b.google.com with SMTP id af79cd13be357-7659cb9c42aso235697585a.3 for ; Sat, 29 Jul 2023 09:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690647324; x=1691252124; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=yhbwdeVAVLw7w1LdIyvCySYdGFtXHpX0EQ+J02OgF0U=; b=dEGwFuN2TtPnnCqswhXXgKZbTaI/LyaH7uLwuU39srOhBfG/jFwEVr+Om8WABl+htd e9QEjLvfWSEst536eH66pyk1vjjoy2jJ0ZMk4fC3j7pvV7hKX+jDpeEeEg1Mj8kIFhEr P0XM46OkPvCVfL047wmCBuzSqx8e8YA7pzdUA9UyWUwZUwOSjRO+NFo8CUpBelXBJAXB 3owEvVYN0YG8WOIwVtDsvJa8AdmILqHfFMExCbmbnv9g691x9pa7tLzrYx3D67RNGj1P w9gnxpdry6iloqAHZRSwbuv0+sQUp2YZz0dWXjvtDl9+yxZlfbvoFWLEXWOKBScwQZKH dYHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690647324; x=1691252124; h=content-transfer-encoding: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=yhbwdeVAVLw7w1LdIyvCySYdGFtXHpX0EQ+J02OgF0U=; b=X+jCy536AEqoA1ipxj/Fan8YL/FSbppuRZbbzTEnNwtMbmHJF821udhf3KJmyhlVPE QXrtPqjfZ7JdPawuRakPd6zQmZcXhtm2mPBKLutDfnJcU/YvMQrLlS2pb2uxeCapfPpu MQ90qD3IjQz4bA/4CK0ELmrYzYmdUOlQkETZJK9k5OMnhuiHucaURuHcqXoBJ0orJ1K3 MVUxI50mnwGFygoEhipKDvakYQI3STpFxi4ivQ2lJ4lqnqMH3Xki2TVh3ozO4mYXP4Tp ITHpn+bEZBJcn1mI8cjl+dABzx/2NPkPtYORikoYHpgQqlJrZiIEa5k5Cq97gmMV0I1Z 88uA== X-Gm-Message-State: ABy/qLYcsdrJViBWyWPcxrXYmg6vatF9yNqh25igHL7T2NSFHB0aia35 aE0B9uDfsIhgvTw3Ks1LacU= X-Google-Smtp-Source: APBJJlGt0Qsc8iu579OjS3dPBYko4Mly73GH0w3PE/9NxRgWO3Bi5UCQgQDNCukiPFPvWPSJIgavVg== X-Received: by 2002:a0c:e287:0:b0:63c:d763:77b4 with SMTP id r7-20020a0ce287000000b0063cd76377b4mr5144562qvl.8.1690647323986; Sat, 29 Jul 2023 09:15:23 -0700 (PDT) Received: from localhost (172.174.245.35.bc.googleusercontent.com. [35.245.174.172]) by smtp.gmail.com with ESMTPSA id p15-20020a0ccb8f000000b0063d06253995sm2152667qvk.22.2023.07.29.09.15.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Jul 2023 09:15:23 -0700 (PDT) Date: Sat, 29 Jul 2023 12:15:23 -0400 From: Willem de Bruijn To: Alexei Starovoitov , Larysa Zaremba Message-ID: <64c53b1b29a66_e235c2942d@willemb.c.googlers.com.notmuch> In-Reply-To: <20230728215340.pf3qcfxh7g4x7s6a@MacBook-Pro-8.local> References: <20230728173923.1318596-1-larysa.zaremba@intel.com> <20230728173923.1318596-13-larysa.zaremba@intel.com> <20230728215340.pf3qcfxh7g4x7s6a@MacBook-Pro-8.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: JL4LFE6P35A5S2SMXRKP76IO3RPOUNWA X-Message-ID-Hash: JL4LFE6P35A5S2SMXRKP76IO3RPOUNWA X-MailFrom: willemdebruijn.kernel@gmail.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, sdf@google.com, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, Willem de Bruijn , Simon Horman X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v4 12/21] xdp: Add checksum hint List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Alexei Starovoitov wrote: > On Fri, Jul 28, 2023 at 07:39:14PM +0200, Larysa Zaremba wrote: > > > > +union xdp_csum_info { > > + /* Checksum referred to by ``csum_start + csum_offset`` is considered > > + * valid, but was never calculated, TX device has to do this, > > + * starting from csum_start packet byte. > > + * Any preceding checksums are also considered valid. > > + * Available, if ``status == XDP_CHECKSUM_PARTIAL``. > > + */ > > + struct { > > + u16 csum_start; > > + u16 csum_offset; > > + }; > > + > > CHECKSUM_PARTIAL makes sense on TX, but this RX. I don't see in the above. It can be observed on RX when packets are looped. This may be observed even in XDP on veth. > > + /* Checksum, calculated over the whole packet. > > + * Available, if ``status & XDP_CHECKSUM_COMPLETE``. > > + */ > > + u32 checksum; > > imo XDP RX should only support XDP_CHECKSUM_COMPLETE with u32 checksum > or XDP_CHECKSUM_UNNECESSARY. > > > +}; > > + > > +enum xdp_csum_status { > > + /* HW had parsed several transport headers and validated their > > + * checksums, same as ``CHECKSUM_UNNECESSARY`` in ``sk_buff``. > > + * 3 least significant bytes contain number of consecutive checksums, > > + * starting with the outermost, reported by hardware as valid. > > + * ``sk_buff`` checksum level (``csum_level``) notation is provided > > + * for driver developers. > > + */ > > + XDP_CHECKSUM_VALID_LVL0 = 1, /* 1 outermost checksum */ > > + XDP_CHECKSUM_VALID_LVL1 = 2, /* 2 outermost checksums */ > > + XDP_CHECKSUM_VALID_LVL2 = 3, /* 3 outermost checksums */ > > + XDP_CHECKSUM_VALID_LVL3 = 4, /* 4 outermost checksums */ > > + XDP_CHECKSUM_VALID_NUM_MASK = GENMASK(2, 0), > > + XDP_CHECKSUM_VALID = XDP_CHECKSUM_VALID_NUM_MASK, > > I don't see what bpf prog suppose to do with these levels. > The driver should pick between 3: > XDP_CHECKSUM_UNNECESSARY, XDP_CHECKSUM_COMPLETE, XDP_CHECKSUM_NONE. > > No levels and no anything partial. please. This levels business is an unfortunate side effect of CHECKSUM_UNNECESSARY. For a packet with multiple checksum fields, what does the boolean actually mean? With these levels, at least that is well defined: the first N checksum fields.