From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DBE2C77B73 for ; Mon, 22 May 2023 15:55:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230434AbjEVPzb (ORCPT ); Mon, 22 May 2023 11:55:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233802AbjEVPz2 (ORCPT ); Mon, 22 May 2023 11:55:28 -0400 Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2948A107; Mon, 22 May 2023 08:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iogearbox.net; s=default2302; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=3XGsqEuFdWjxpRIwiAwzbMYLJommpBUmf64o8Q70T54=; b=T3DhWwZvaaFpz7BUKGUYfo2SjO mnHOu0gFWqbJdNvvfVMzsr7HWt0aV5MpevFsuyJDWdKAo8zr+5Rr3x+VXBd7yRgncbklJv2GjuJE3 t2VSzBIMvOhxun/YpvaQFaAGsDsRp6wyc394DMMtDoEB8tgIWkvIcOAgv4NdzapSXJ0iQCe54RrPd 0zPEZgqJx3JbokWMmV+2Ogv8aCbxI9qghhH2GTaSbJzclGz2cCUQYjURJYo+VbsDvxjitAIFTXL5r 6iyrrvcncV1twi+CoqplMGnBBFpIZ34k0ah6ZLAyhs3Hzf4qz8B01wfMdibZXOOQCYQn9Jyzya9HV lJdNJQmw==; Received: from sslproxy06.your-server.de ([78.46.172.3]) by www62.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q17sN-000HgE-IO; Mon, 22 May 2023 17:55:11 +0200 Received: from [85.1.206.226] (helo=linux.home) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q17sM-000UFQ-IZ; Mon, 22 May 2023 17:55:10 +0200 Subject: Re: [PATCH RESEND bpf-next 14/15] net, xdp: allow metadata > 32 To: Alexander Lobakin , Jesper Dangaard Brouer Cc: brouer@redhat.com, Larysa Zaremba , bpf@vger.kernel.org, Stanislav Fomichev , Alexei Starovoitov , Andrii Nakryiko , Jakub Kicinski , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Jiri Olsa , Jesse Brandeburg , Tony Nguyen , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org References: <20230512152607.992209-1-larysa.zaremba@intel.com> <20230512152607.992209-15-larysa.zaremba@intel.com> <5b817d49-eefa-51c9-3b51-01f1dba17d42@intel.com> From: Daniel Borkmann Message-ID: <106900e6-ab94-b37f-dc9d-f0a4242bb90f@iogearbox.net> Date: Mon, 22 May 2023 17:55:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.8/26915/Mon May 22 09:23:18 2023) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/22/23 5:28 PM, Alexander Lobakin wrote: > From: Jesper Dangaard Brouer > Date: Mon, 22 May 2023 13:41:43 +0200 >> On 19/05/2023 18.35, Alexander Lobakin wrote: >>> From: Jesper Dangaard Brouer >>> Date: Tue, 16 May 2023 17:35:27 +0200 > > [...] > >> Not talking about your changes (in this patch). >> >> I'm realizing that SKBs using metadata area will have a performance hit >> due to accessing another cacheline (the meta_len in skb_shared_info). >> >> IIRC Daniel complained about this performance hit (in the past), I guess >> this explains it.  IIRC Cilium changed to use percpu variables/datastore >> to workaround this. > > Why should we compare metadata of skbs on GRO anyway? I was disabling it > the old hints series (conditionally, if driver asks), moreover... > ...if metadata contains full checksum, GRO will be broken completely due > to this comparison (or any other frame-unique fields. VLAN tags and > hashes are okay). This is when BPF prog on XDP populates metadata with custom data when it wants to transfer information from XDP to skb aka tc BPF prog side. percpu data store may not work here as it is not guaranteed that skb might end up on same CPU. >>> The whole xdp_metalen_invalid() gets expanded into: >>> >>>     return (metalen % 4) || metalen > 255; >>> >>> at compile-time. All those typeof shenanigans are only to not open-code >>> meta_len's type/size/max. >>> >>>> >>>> But only use for SKBs that gets created from xdp with metadata, right? >>>> >> >> Normal netstack processing actually access this skb_shinfo->meta_len in >> gro_list_prepare().  As the caller dev_gro_receive() later access other >> memory in skb_shared_info, then the GRO code path already takes this hit >> to begin with. > > You access skb_shinfo() often even before running XDP program, for > example, when a frame is multi-buffer. Plus HW timestamps are also > there, and so on.