Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3618821pxb; Sat, 13 Feb 2021 03:56:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJzqJJQUS+8PgRw2djK8uaaGA1qQH9cEkM+2H4r0OYAUMeroUTN9JGkEB9dhk2RJzPJSTxI1 X-Received: by 2002:a17:907:28c9:: with SMTP id en9mr7258846ejc.314.1613217386101; Sat, 13 Feb 2021 03:56:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613217386; cv=none; d=google.com; s=arc-20160816; b=m5aFrEeggESVc7VsYcL0pCXCFmp+KN9WZbQUv5UExjFQ8ARmgroXip3BlGMgsYFsyr PF1cvTuGJ0fgZNobOH/Cpo+EDk0/keLaTLBlpaoxh1zOWMsFf6axKEOURW2oCUCgInXU QS/hmYa06HvvHBUvEqpQph2zjzuPKZl7Ds5wzl41ZI9IUJM/i2yQUCPWVff9e+roaRH3 i5XovbhkPfK+GM5TLRKJPpeZ9Ql34gGpvazfz/CdeIMsdQZnnxSF7NNXl2dNOsJgUT1N bIfQz3Str+thr/GQwoTRvRO23uV/Purq5qLjmXU3OAj/16eTTJl3jXQLbw9u9vpHiQt0 sDeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:reply-to:cc:from:to :dkim-signature:date; bh=U9h7ecCA02bgXdLGxxosUvrTLcI+jIc/SZnrWbn3k90=; b=qmxQOzRMfafke3ispeNeShIGBVI2G0Q8KO1H0k4g9wqzqS7mMVvH0cFFuQNcvE2Rtp vMwveIagis7ErvZQtiGwXOX07jfeaNu46zsRwbdkegFd00t96GzsMblIezSK9Vv/YyGd Emqu3cRq6lMX2oHTVCIHYsyXzNcd84fO88yvvpw50iG6xNqiAMSmVYHOxGdMTiuw02SJ af9Qm9bSejGziucnR19VmqYegTseDWR9w4HdzFX3ZRc35X8oDneDRcOhfs/glGsnzaTT Pgow/bVX0tzUSu1OxJ7TsGgppiBMT0W0OPLvTfxujICq1XiXNQoTaCYti4xEbrKxnOs8 WjuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pm.me header.s=protonmail header.b=ZMq4DHhr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=pm.me Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p17si8441977edw.347.2021.02.13.03.55.49; Sat, 13 Feb 2021 03:56:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@pm.me header.s=protonmail header.b=ZMq4DHhr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=pm.me Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229584AbhBMLyK (ORCPT + 99 others); Sat, 13 Feb 2021 06:54:10 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:51124 "EHLO mail-40131.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229517AbhBMLyJ (ORCPT ); Sat, 13 Feb 2021 06:54:09 -0500 Date: Sat, 13 Feb 2021 11:53:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1613217205; bh=U9h7ecCA02bgXdLGxxosUvrTLcI+jIc/SZnrWbn3k90=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=ZMq4DHhrTAzzviEoROqpXjW+tTJgetKNneTLYWBIlq1hjBTgqXgIdVKLHdwApgF7D v6L+0+0nn2UAdmV3DHCnIKrIcYo3rYVJfsas0IkWgFG1DFZ4ISVs+MUGiqZikiQ5cu zgqi1RJsyMOhvehrQ0f88EyM8+UGaK/FXcLBFOtbzEfdNQ50aP3QQzCevV27iIoNk3 lWwWv3QRAwYmKvAA823cwxis7+DpyMK6eB0dh9BfcGG0sZlxUwme2Y41HSFgbrci0Y +YCAKrVwxz45r9IAYqW+hXstZ1PBaISrHf+hxT5PA5XPhcCA3C91XpOaKUCTJBUl5y YyC7MAAwCewEg== To: Alexander Duyck From: Alexander Lobakin Cc: Alexander Lobakin , "David S. Miller" , Jakub Kicinski , Jonathan Lemon , Eric Dumazet , Dmitry Vyukov , Willem de Bruijn , Randy Dunlap , Kevin Hao , Pablo Neira Ayuso , Jakub Sitnicki , Marco Elver , Dexuan Cui , Paolo Abeni , Jesper Dangaard Brouer , Alexander Duyck , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Taehee Yoo , Cong Wang , =?utf-8?Q?Bj=C3=B6rn_T=C3=B6pel?= , Miaohe Lin , Guillaume Nault , Yonghong Song , zhudi , Michal Kubecek , Marcelo Ricardo Leitner , Dmitry Safonov <0x7f454c46@gmail.com>, Yang Yingliang , Florian Westphal , Edward Cree , LKML , Netdev Reply-To: Alexander Lobakin Subject: Re: [PATCH v5 net-next 09/11] skbuff: allow to optionally use NAPI cache from __alloc_skb() Message-ID: <20210213115229.2728-1-alobakin@pm.me> In-Reply-To: References: <20210211185220.9753-1-alobakin@pm.me> <20210211185220.9753-10-alobakin@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alexander Duyck Date: Thu, 11 Feb 2021 19:18:45 -0800 > On Thu, Feb 11, 2021 at 11:00 AM Alexander Lobakin wrote= : > > > > Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get > > an skbuff_head from the NAPI cache instead of inplace allocation > > inside __alloc_skb(). > > This implies that the function is called from softirq or BH-off > > context, not for allocating a clone or from a distant node. > > > > Signed-off-by: Alexander Lobakin > > --- > > net/core/skbuff.c | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > > index 9e1a8ded4acc..a0b457ae87c2 100644 > > --- a/net/core/skbuff.c > > +++ b/net/core/skbuff.c > > @@ -397,15 +397,20 @@ struct sk_buff *__alloc_skb(unsigned int size, gf= p_t gfp_mask, > > struct sk_buff *skb; > > u8 *data; > > bool pfmemalloc; > > + bool clone; > > > > - cache =3D (flags & SKB_ALLOC_FCLONE) > > - ? skbuff_fclone_cache : skbuff_head_cache; > > + clone =3D !!(flags & SKB_ALLOC_FCLONE); >=20 > The boolean conversion here is probably unnecessary. I would make > clone an int like flags and work with that. I suspect the compiler is > doing it already, but it is better to be explicit. >=20 > > + cache =3D clone ? skbuff_fclone_cache : skbuff_head_cache; > > > > if (sk_memalloc_socks() && (flags & SKB_ALLOC_RX)) > > gfp_mask |=3D __GFP_MEMALLOC; > > > > /* Get the HEAD */ > > - skb =3D kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, nod= e); > > + if ((flags & SKB_ALLOC_NAPI) && !clone && >=20 > Rather than having to do two checks you could just check for > SKB_ALLOC_NAPI and SKB_ALLOC_FCLONE in a single check. You could just > do something like: > if ((flags & (SKB_ALLOC_FCLONE | SKB_ALLOC_NAPI) =3D=3D SKB_ALLOC_NAP= I) >=20 > That way you can avoid the extra conditional jumps and can start > computing the flags value sooner. I thought about combined check for two flags yesterday, so yeah, that probably should be better than the current version. > > + likely(node =3D=3D NUMA_NO_NODE || node =3D=3D numa_mem_id(= ))) > > + skb =3D napi_skb_cache_get(); > > + else > > + skb =3D kmem_cache_alloc_node(cache, gfp_mask & ~GFP_DM= A, node); > > if (unlikely(!skb)) > > return NULL; > > prefetchw(skb); > > @@ -436,7 +441,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_= t gfp_mask, > > __build_skb_around(skb, data, 0); > > skb->pfmemalloc =3D pfmemalloc; > > > > - if (flags & SKB_ALLOC_FCLONE) { > > + if (clone) { > > struct sk_buff_fclones *fclones; > > > > fclones =3D container_of(skb, struct sk_buff_fclones, s= kb1); > > -- > > 2.30.1 Thanks, Al