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 X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F674C04AAF for ; Tue, 21 May 2019 06:08:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 575CF20863 for ; Tue, 21 May 2019 06:08:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20150623.gappssmtp.com header.i=@resnulli-us.20150623.gappssmtp.com header.b="gmU67eDk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727933AbfEUGI5 (ORCPT ); Tue, 21 May 2019 02:08:57 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:52310 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727910AbfEUGI5 (ORCPT ); Tue, 21 May 2019 02:08:57 -0400 Received: by mail-wm1-f65.google.com with SMTP id y3so1543231wmm.2 for ; Mon, 20 May 2019 23:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=exCu3QKdPXG3iAIqpcvr8DtpfdrIsoLY0jQqeeMKEUc=; b=gmU67eDkeeqBzP0M8Qcsycwi/62mK8W5tsJHuv1oAr1OTB1JTLYcLq4nvdaGqdSf3V pGe3VPYCvpKM8EhrEPIRODMtxU5vTClXNkmJlPGgk3wZD7EJgEmhfYbUEMkXF4t3SrnP jjpnLYbdIyNdYNIVA5G9sZAh2887027RGI2ktvgugxLbCGhsUXUeh9/Uw3lrCSD5vf/u 0EOtSQze1e4gJgkjjWfpyMnS//r9d1KHMnXYUmCdonFn4IzUaoTuTTx4Eo81OkpyYQTX oEN8rofLHzsYB+8gblSJbNIk6VrKwR+vO3A9q0QhCPvz5uOJYjHBmA+FUNjCxA/IvtyN zskQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=exCu3QKdPXG3iAIqpcvr8DtpfdrIsoLY0jQqeeMKEUc=; b=HdsBS4ro7NHRCjU2fscJlFbjvvjOcLb/1FrvGvjMOfqiZkwGF0MyfWobXl93+OfupO UyQeVTMuKTcYHpFV6lW4wKqYEm4Po+ER3nGE3jED49fS6yhl6PxJQVv+DV9wXkPwckqj 73+Pw8uKRO6abTteqU1v06YvXqPw1gHdx4h7AMNFEG9BlASF9OH7HpdCBcX2qXuEK47u VAV3rZcj7nTT325IoX1nvmLJlnvDlSxbPRSqmvqtBhZ3IqccH8K/A3tCkMfFv+0cSMOu 8IXTOd1eAtRNK9oE0/x0+uwKE6+3XTK9ouQPjBPs+u3ZaNA4qFDPoYkgNRQyqoyE8x7M bzow== X-Gm-Message-State: APjAAAXKemn2HPmdIgHiFVGzoM583mUnY8GP+JNGnLbQZqUY5irdx3v8 mRo0yxad5917roQPbPutx6R4gw== X-Google-Smtp-Source: APXvYqwSEbNc2NPFa2mP57c05IYJ8Zpjrn942MM5szoSC6xFaqh4p2NExi6ZHYY3wh6fFLstjhPEWg== X-Received: by 2002:a1c:7dd6:: with SMTP id y205mr1861594wmc.90.1558418934716; Mon, 20 May 2019 23:08:54 -0700 (PDT) Received: from localhost (jirka.pirko.cz. [84.16.102.26]) by smtp.gmail.com with ESMTPSA id q11sm2299728wmc.15.2019.05.20.23.08.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 May 2019 23:08:54 -0700 (PDT) Date: Tue, 21 May 2019 08:08:53 +0200 From: Jiri Pirko To: Jason Wang Cc: Stephen Hemminger , netdev@vger.kernel.org, davem@davemloft.net, xdp-newbies@vger.kernel.org, bpf@vger.kernel.org, Stephen Hemminger Subject: Re: [PATCH v2 net 2/2] net: core: generic XDP support for stacked device Message-ID: <20190521060853.GA2210@nanopsycho.orion> References: <20190519031046.4049-1-sthemmin@microsoft.com> <20190519031046.4049-3-sthemmin@microsoft.com> <20190520091105.GA2142@nanopsycho> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Tue, May 21, 2019 at 06:47:23AM CEST, jasowang@redhat.com wrote: > >On 2019/5/20 下午5:11, Jiri Pirko wrote: >> Sun, May 19, 2019 at 05:10:46AM CEST, stephen@networkplumber.org wrote: >> > When a device is stacked like (team, bonding, failsafe or netvsc) the >> > XDP generic program for the parent device is not called. In these >> > cases, the rx handler changes skb->dev to its own in the receive >> > handler, and returns RX_HANDLER_ANOTHER. Fix this by calling >> > do_xdp_generic if necessary before starting another round. >> > >> > Review of all the places RX_HANDLER_ANOTHER is returned >> > show that the current devices do correctly change skb->dev. >> > >> > There was an older patch that got abandoned that did the >> > same thing, this is just a rewrite. >> > >> > Suggested-by: Jason Wang >> > Fixes: d445516966dc ("net: xdp: support xdp generic on virtual devices") >> > Signed-off-by: Stephen Hemminger >> > Acked-by: Jason Wang >> > --- >> > net/core/dev.c | 10 ++++++++++ >> > 1 file changed, 10 insertions(+) >> > >> > diff --git a/net/core/dev.c b/net/core/dev.c >> > index b6b8505cfb3e..240d0b2de1a8 100644 >> > --- a/net/core/dev.c >> > +++ b/net/core/dev.c >> > @@ -4921,6 +4921,16 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc, >> > ret = NET_RX_SUCCESS; >> > goto out; >> > case RX_HANDLER_ANOTHER: >> > + if (static_branch_unlikely(&generic_xdp_needed_key)) { >> > + struct bpf_prog *xdp_prog; >> > + >> > + xdp_prog = rcu_dereference(skb->dev->xdp_prog); >> > + ret = do_xdp_generic(xdp_prog, skb); >> > + if (ret != XDP_PASS) { >> > + ret = NET_RX_SUCCESS; >> > + goto out; >> > + } >> > + } >> I'm always scarred of changes like this. The history tells us that this >> codepaths are very fragile. It took us non-trivial efford to fix bonding >> here, not to mention vlans (that was pain). > > >I may miss something, did you see any issue for bonding with this patch? No, I was talking about past. > > >> >> The reason for troubles was often fact that different flows were treated >> differently (vlan accel/non-accel). > > >Do you mean we need do something similar after vlan_do_receive() returns >true? No. > > >> This patch calls do_xdp_generic for master device in different point in >> the receive patch comparing to lower device. Would it be possible to >> unify this? E.g. by moving do_xdp_generice() call from >> netif_rx_internal()/netif_receive_skb_internal() here, >> to the beginning of __netif_receive_skb_core()? > > >Probably just after another_round label. And this means generic XDP is done >after RPS which could be even better. Yes. That is exactly the place I have in mind. > >Thanks > > >> >> >> >> > goto another_round; >> > case RX_HANDLER_EXACT: >> > deliver_exact = true; >> > -- >> > 2.20.1 >> >