From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net-next] net: avoid unneeded atomic operation in ip*_append_data() Date: Wed, 4 Apr 2018 06:26:37 -0700 Message-ID: References: <7e55c93c2c7cddf4c077aa77aa1ab58396f502ff.1522844999.git.pabeni@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Eric Dumazet To: Paolo Abeni , netdev@vger.kernel.org Return-path: Received: from mail-pl0-f48.google.com ([209.85.160.48]:45947 "EHLO mail-pl0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbeDDN0j (ORCPT ); Wed, 4 Apr 2018 09:26:39 -0400 Received: by mail-pl0-f48.google.com with SMTP id v18-v6so11972986ply.12 for ; Wed, 04 Apr 2018 06:26:39 -0700 (PDT) In-Reply-To: <7e55c93c2c7cddf4c077aa77aa1ab58396f502ff.1522844999.git.pabeni@redhat.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 04/04/2018 05:30 AM, Paolo Abeni wrote: > After commit 694aba690de0 ("ipv4: factorize sk_wmem_alloc updates > done by __ip_append_data()") and commit 1f4c6eb24029 ("ipv6: > factorize sk_wmem_alloc updates done by __ip6_append_data()"), > when transmitting sub MTU datagram, an addtional, unneeded atomic > operation is performed in ip*_append_data() to update wmem_alloc: > in the above condition the delta is 0. > > The above cause small but measurable performance regression in UDP > xmit tput test with packet size below MTU. > > This change avoids such overhead updating wmem_alloc only if > wmem_alloc_delta is non zero. > > The error path is left intentionally unmodified: it's a slow path > and simplicity is preferred to performances. > > Fixes: 694aba690de0 ("ipv4: factorize sk_wmem_alloc updates done by __ip_append_data()") > Fixes: 1f4c6eb24029 ("ipv6: factorize sk_wmem_alloc updates done by __ip6_append_data()") > Signed-off-by: Paolo Abeni > --- SGTM, thanks Paolo Reviewed-by: Eric Dumazet My intent was to modify sock_alloc_send_pskb() to accept to opt-out the skb_set_owner_w() call, but I forgot that the merge window was starting last week-end. So if a UDP datagram needs 2 skb, only one sk_wmem_alloc change would happen, not 1 + 1.