From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mail.toke.dk (Postfix) with ESMTPS id 1305B982CDE for ; Tue, 28 Jun 2022 21:49:30 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=Ygo03K8i DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656445771; x=1687981771; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SutG8vtwjgxHponFr0JSgxWBk/og3Hhe0diuNsWKHbE=; b=Ygo03K8iaGctsJXhB1qATfdkNGd8vy+l6Ho1lM2juFsv0CvLUH8rEog6 iEI+3PoHh+qIMK/fZBD0B1aJzJdjoGPLLK2U1ik5ExxKUBeNvRZr5uEwh gvWF40JqevBtCFxfYgowSh8KyySv7xQxi2R2MjXAdPm4whLAO+Xh3GEYY Y3vh0h2HQfHGM9PSuTd9mpUqNpK+frQxSZ4NQezgXfW+etc+LOOuMOC7o qMlZqvgRP5HPccTSBRZKNhJKvHLE7vxdA5TSCOrVtkEd5vamDWWL1ifX/ 3EOTRSb3n/cCbYk/5RAq87rRjiwkGAMEJBhSP1oSymUmiwfj9hv/nTA3c w==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="368146909" X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="368146909" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 12:49:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="732883398" Received: from irvmail001.ir.intel.com ([10.43.11.63]) by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2022 12:49:25 -0700 Received: from newjersey.igk.intel.com (newjersey.igk.intel.com [10.102.20.203]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 25SJmr9M022013; Tue, 28 Jun 2022 20:49:23 +0100 From: Alexander Lobakin To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Date: Tue, 28 Jun 2022 21:47:42 +0200 Message-Id: <20220628194812.1453059-23-alexandr.lobakin@intel.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220628194812.1453059-1-alexandr.lobakin@intel.com> References: <20220628194812.1453059-1-alexandr.lobakin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: CXNZSYTMBW5FNZRT3A7BOIF2V64XXV7K X-Message-ID-Hash: CXNZSYTMBW5FNZRT3A7BOIF2V64XXV7K X-MailFrom: alexandr.lobakin@intel.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: Alexander Lobakin , Larysa Zaremba , Michal Swiatkowski , Jesper Dangaard Brouer , =?UTF-8?q?Bj=C3=B6rn=20T=C3=B6pel?= , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , Toke Hoiland-Jorgensen , Lorenzo Bianconi , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jesse Brandeburg , John Fastabend , Yajun Deng , Willem de Bruijn , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] [PATCH RFC bpf-next 22/52] net, skbuff: add ability to skip skb metadata comparison List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Some XDP metadata fields maybe be unique from frame to frame, not necessarily indicating that it's from a different flow. This includes frame checksums, timestamps etc. The drivers usually carry the metadata to skbs along with the payload, and the GRO layer tries to compare the metadata of the frames. This not only leads to perf regressions (esp. given that metadata can now be larger than 32 bytes -> a slower call to memmp() will be used), but also breaks frame coalescing at all. To avoid that, add an skb flag indicating that the metadata can carry unique values and thus should not be compared. If at least one of the skbs passed to skb_metadata_differs() carries it, the function will then immediately return reporting that they're identical. The underscored version of the function is not affected, allowing to explicitly compare the meta if needed. The flag is being cleared on pskb_expand_head() when the skb_shared_info::meta_len gets zeroed. Signed-off-by: Alexander Lobakin --- include/linux/skbuff.h | 18 ++++++++++++++++++ net/core/skbuff.c | 1 + 2 files changed, 19 insertions(+) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index a825ea7f375d..1c308511acbb 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -509,6 +509,11 @@ enum { * charged to the kernel memory. */ SKBFL_PURE_ZEROCOPY = BIT(2), + + /* skb metadata may contain unique values such as checksums + * and we should not compare it against others. + */ + SKBFL_METADATA_NOCOMP = BIT(3), }; #define SKBFL_ZEROCOPY_FRAG (SKBFL_ZEROCOPY_ENABLE | SKBFL_SHARED_FRAG) @@ -4137,6 +4142,9 @@ static inline bool skb_metadata_differs(const struct sk_buff *skb_a, if (!(len_a | len_b)) return false; + if ((skb_shinfo(skb_a)->flags | skb_shinfo(skb_b)->flags) & + SKBFL_METADATA_NOCOMP) + return false; return len_a != len_b ? true : __skb_metadata_differs(skb_a, skb_b, len_a); @@ -4152,6 +4160,16 @@ static inline void skb_metadata_clear(struct sk_buff *skb) skb_metadata_set(skb, 0); } +static inline void skb_metadata_nocomp_set(struct sk_buff *skb) +{ + skb_shinfo(skb)->flags |= SKBFL_METADATA_NOCOMP; +} + +static inline void skb_metadata_nocomp_clear(struct sk_buff *skb) +{ + skb_shinfo(skb)->flags &= ~SKBFL_METADATA_NOCOMP; +} + struct sk_buff *skb_clone_sk(struct sk_buff *skb); #ifdef CONFIG_NETWORK_PHY_TIMESTAMPING diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 00bf35ee8205..5b23fc7f1157 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1750,6 +1750,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail, atomic_set(&skb_shinfo(skb)->dataref, 1); skb_metadata_clear(skb); + skb_metadata_nocomp_clear(skb); /* It is not generally safe to change skb->truesize. * For the moment, we really care of rx path, or -- 2.36.1