From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by mail.toke.dk (Postfix) with ESMTPS id A2D4DA1B353 for ; Fri, 21 Jul 2023 00:24:33 +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=pNYm1IKR Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-63759b5983dso8352946d6.0 for ; Thu, 20 Jul 2023 15:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689891871; x=1690496671; 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=mbN75j8y8eFg2bbOR60vga2vIDgL+4CQKTZqLo7f94w=; b=pNYm1IKRTPdaXOKZv7W0MUTVZqwuqU1gkOYDfGeKR+aoLqjNBC1slosDkX9HvZHSYu HWluSic8xeCopahNgt+r3m7CLUXE5LtHQYtreUhDlqVmgk8Zjw06Bui+RkESmhrqGc2A c+16xYbBjfuFXag8ayOYKQYXALu4icVK1d5FlmpV8B3Pu4aopDuC2tYVBpqFKnVUmjj3 qi+A2D1ytVxejQom+i2cIrTUoNcsURdcjQNZdIt1TwtdTXeCdQ1fsm/GxkXIVOdttsMr KGX6dH7YSe2GSCsqDYD5O8kAfzSUwWtwtvyZV4qvmxu5hAqvrbg8NWiuShRAstvJh9h7 w/xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689891871; x=1690496671; 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=mbN75j8y8eFg2bbOR60vga2vIDgL+4CQKTZqLo7f94w=; b=CU+ENZmYqFAd29XZ0w1Zn+0dwipFowTzCkstrT1ZS/V76LtaieovKxpEAWb6xXktSm Dm3DST91BNaZsW+HDHGZPPNQIUrwPYlyzyNxNHN6DNlnac+K2WvKyoe59RYItVJkPsUx Ewdvs3ipq89iiAi6bn2BtTkAYgXOZfo01KThK3lMwaidyzZOVXf8s4xqYUTha1pFLV1k nNfeBiFg7GFnU9wmf6VkLYMpRl3uXCpSYk9O4nw/ny9KI0jNOJ4FKrr6qy8luWUMNJdZ OVT6pz2pgm/ICez5tajTyLvSbm79o+7/fOjDlMBP1lHUHb7bZ6psztI7sOLCxZgBip8F wZOw== X-Gm-Message-State: ABy/qLaXhTbihms9ED+6ucYR+ku9HdKsI6YJdKSA+dwx6/nsZ+uthbsO rT+NeJEhHBZ6u+XQCRDh9BI= X-Google-Smtp-Source: APBJJlEoHWHnn4n3QMGReuVNwzEGNfUOe4J1EvjlU6RyB78kDh/eXyd/85vwmkh1GTYOIKioBbAOHA== X-Received: by 2002:a0c:aa18:0:b0:637:49c7:28e4 with SMTP id d24-20020a0caa18000000b0063749c728e4mr326501qvb.5.1689891871613; Thu, 20 Jul 2023 15:24:31 -0700 (PDT) Received: from localhost (172.174.245.35.bc.googleusercontent.com. [35.245.174.172]) by smtp.gmail.com with ESMTPSA id a26-20020a0cb35a000000b006166d870243sm791277qvf.43.2023.07.20.15.24.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 15:24:31 -0700 (PDT) Date: Thu, 20 Jul 2023 18:24:30 -0400 From: Willem de Bruijn To: Stanislav Fomichev , larysa.zaremba@intel.com Message-ID: <64b9b41eea18b_2c3d5029438@willemb.c.googlers.com.notmuch> In-Reply-To: References: <20230719183734.21681-1-larysa.zaremba@intel.com> <20230719183734.21681-14-larysa.zaremba@intel.com> <20230719185930.6adapqctxfdsfmye@macbook-pro-8.dhcp.thefacebook.com> <64b85ad52d012_2849c1294df@willemb.c.googlers.com.notmuch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: BVSJKNK4RJF5LZLR3CIYWCH22SIHUV4A X-Message-ID-Hash: BVSJKNK4RJF5LZLR3CIYWCH22SIHUV4A 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: Alexei Starovoitov , Willem de Bruijn , "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" , David Ahern , Jakub Kicinski , Willem de Bruijn , brouer@redhat.com, anatoly.burakov@intel.com, aleksander.lobakin@intel.com, Magnus Karlsson , mtahhan@redhat.com, "xdp-hints@xdp-project.net" , "netdev@vger.kernel.org" X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v3 13/21] ice: Implement checksum hint List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Stanislav Fomichev wrote: > On 07/20, Zaremba, Larysa wrote: > > On Thu, Jul 20, 2023 at 08:14:52AM -0700, Alexei Starovoitov wrote: > > > On Thu, Jul 20, 2023 at 2:47=E2=80=AFAM Zaremba, Larysa > > > wrote: > > > > > > > > On Wed, Jul 19, 2023 at 05:51:17PM -0400, Willem de Bruijn wrote:= > > > > > Alexei Starovoitov wrote: > > > > > > On Wed, Jul 19, 2023 at 08:37:26PM +0200, Larysa Zaremba wrot= e: > > > > > > > Implement .xmo_rx_csum callback to allow XDP code to determ= ine, > > > > > > > whether HW has validated any checksums. > > > > > > > > > > > > > > Signed-off-by: Larysa Zaremba > > > > > > > --- > > > > > > > drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 29 +++++++= ++++++++++++ > > > > > > > 1 file changed, 29 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c = b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c > > > > > > > index 54685d0747aa..6647a7e55ac8 100644 > > > > > > > --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c > > > > > > > +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c > > > > > > > @@ -660,8 +660,37 @@ static int ice_xdp_rx_vlan_tag(const s= truct xdp_md *ctx, u16 *vlan_tci, > > > > > > > return 0; > > > > > > > } > > > > > > > > > > > > > > +/** > > > > > > > + * ice_xdp_rx_csum_lvl - Get level, at which HW has checke= d the checksum > > > > > > > + * @ctx: XDP buff pointer > > > > > > > + * @csum_status: destination address > > > > > > > + * @csum_info: destination address > > > > > > > + * > > > > > > > + * Copy HW checksum level (if was checked) to the destinat= ion address. > > > > > > > + */ > > > > > > > +static int ice_xdp_rx_csum(const struct xdp_md *ctx, > > > > > > > + enum xdp_csum_status *csum_status, > > > > > > > + union xdp_csum_info *csum_info) > > > > > > > +{ > > > > > > > + const struct ice_xdp_buff *xdp_ext =3D (void *)ctx; > > > > > > > + const union ice_32b_rx_flex_desc *eop_desc; > > > > > > > + enum ice_rx_csum_status status; > > > > > > > + u16 ptype; > > > > > > > + > > > > > > > + eop_desc =3D xdp_ext->pkt_ctx.eop_desc; > > > > > > > + ptype =3D ice_get_ptype(eop_desc); > > > > > > > + > > > > > > > + status =3D ice_get_rx_csum_status(eop_desc, ptype); > > > > > > > + if (status & ICE_RX_CSUM_NONE) > > > > > > > + return -ENODATA; > > > > > > > + > > > > > > > + *csum_status =3D ice_rx_csum_lvl(status) + 1; > > = > > I'll duplicate an improved version of this line from another thread i= n case it = > > could help with the comprehension during review: > > = > > *csum_status =3D XDP_CHECKSUM_VALID_LVL0 + ice_rx_csum_lvl(status); > > = > > > > > > > + return 0; > > > > > > > +} > > > > > > > > > > > > and xdp_csum_info from previous patch left uninitialized? > > > > > > What was the point adding it then? > > > > > > > > > > I suppose this driver only returns CHECKSUM_NONE or > > > > > CHECKSUM_UNNECESSARY? Also based on a grep of the driver dir. > > > > > > > > > > > > > Yes, correct, current ice HW cannot produce complete checksum, > > > > so only CHECKSUM_UNNECESSARY for known protocols, CHECKSUM_NONE o= therwise, > > > > nothing to initialize csum_info with in either case. > > > > > > > > xdp_csum_info is initialized in veth implementation though, but o= nly > > > > csum_start/offset, so complete XDP checksum has no users in this = patchset. > > > > Is this a problem? > > > > > > > > In previous version I had CHECKSUM_UNNECESSARY-only kfunc, but I = think everyone > > > > has agreed, csum hint kfunc should give more comprehensive output= . > > > = > > > csum kfunc supposed to be generic. > > > If for ICE it fills in one argument and for veth another then the w= hole > > > idea of generic api is not working. > > = > > Both ice and veth fill in the csum_status, the need to fill in the cs= um_info is = > > determined by the status. I don not see a problem with that. > > = > > Maybe you have an issue with putting a valid checksum number into a s= tatus = > > instead of info? Please clarify. > = > +1, that seems to match skb interface > = > Regarding 'generic api not working' in general: I think we've discussed= > that with this 'flexible' kfunc format we can allow non-generic kfuncs = for > specific devices if we think that it makes sense to > differentiate/experiment/etc. Do you think it makes sense to go > non-generic route here? I think we should expose the standard CHECKSUM_* behavior. The current encoding captures all four types. Which type is returned is not necessarily defined only by the device. Some devices can return CHECKSUM_NONE for some packets, CHECKSUM_PARTIAL for others and CHECKSUM_UNNECESSARY for a third set (e.g., mlx4). Specializing the return type to the device would not simplify the struct.