From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Subject: Re: [PATCH][RFC] udp: cache sock to avoid searching it twice Date: Fri, 09 Nov 2018 14:41:24 +0100 Message-ID: <2b32d67c09bbdec46b97a3cf2898145ce60a6836.camel@redhat.com> References: <1541744479-12810-1-git-send-email-lirongqing@baidu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Willem de Bruijn To: Li RongQing , netdev@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37556 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727784AbeKIXWH (ORCPT ); Fri, 9 Nov 2018 18:22:07 -0500 In-Reply-To: <1541744479-12810-1-git-send-email-lirongqing@baidu.com> Sender: netdev-owner@vger.kernel.org List-ID: Hi, Adding Willem, I think he can be interested. On Fri, 2018-11-09 at 14:21 +0800, Li RongQing wrote: > GRO for UDP needs to lookup socket twice, first is in gro receive, > second is gro complete, so if store sock to skb to avoid looking up > twice, this can give small performance boost > > netperf -t UDP_RR -l 10 > > Before: > Rate per sec: 28746.01 > After: > Rate per sec: 29401.67 > > Signed-off-by: Li RongQing > --- > net/ipv4/udp_offload.c | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c > index 0646d61f4fa8..429570112a33 100644 > --- a/net/ipv4/udp_offload.c > +++ b/net/ipv4/udp_offload.c > @@ -408,6 +408,11 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb, > > if (udp_sk(sk)->gro_enabled) { > pp = call_gro_receive(udp_gro_receive_segment, head, skb); > + > + if (!IS_ERR(pp) && NAPI_GRO_CB(pp)->count > 1) { > + sock_hold(sk); > + pp->sk = sk; > + } > rcu_read_unlock(); > return pp; > } What if 'pp' is NULL? Aside from that, this replace a lookup with 2 atomic ops, and only when such lookup is amortized on multiple aggregated packets: I'm unsure if it's worthy and I don't understand how that improves RR tests (where the socket can't see multiple, consecutive skbs, AFAIK). Cheers, Paolo