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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 A79C8C04AAC for ; Mon, 20 May 2019 15:53:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6D01F2171F for ; Mon, 20 May 2019 15:53:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="AknxJqb/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392376AbfETPxo (ORCPT ); Mon, 20 May 2019 11:53:44 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:42923 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392375AbfETPxn (ORCPT ); Mon, 20 May 2019 11:53:43 -0400 Received: by mail-pl1-f194.google.com with SMTP id x15so6908128pln.9 for ; Mon, 20 May 2019 08:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LEDUdN4h7CJGbK0Ho7cpn+GdpkHhGHnX5CljcvGCU28=; b=AknxJqb/SvO7MqGBjcbD3Q1MrhxlWuhNtNr6+if4RueqArvk0CaDdrnmY3fJWXn+PH Wn2By67kwExDmGrJuxC7i7lAiu4aN/Gz2pM2idLEHGiK7GGtEYl6CHQSTNJ2IOnixVBQ gWJsZCVndjFeXvUq19Aia0n/90IZ+u7MKhIOmjwui8Df4Ni1hlIGXOkJGeBC7890Rwhk oOuYKiFBQEa/i/MJLlJnmhoxupX3/STPHXewb5RJVCG/c2kAlGdZE6eYl808/W+er2wV N6R88Wh7JzsQBslYCC/s/0l9lWpc1RJmETX5OW7984KGJh242Z2qjx2xHDheH975Vv62 vN5w== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=LEDUdN4h7CJGbK0Ho7cpn+GdpkHhGHnX5CljcvGCU28=; b=aQFmMk0WRyJ+H6on5iF6HqeVO2+0QSGIS/n/OXS2cSkXJc68bJlbW9mGMbPKcjTMOc LLF+aLlUaJyxCtJ3qPm6oP0HlRoneRd0CPKJquQ3mAeLOVHjQqqeUx8IcmHZmiPHPIMw MjUVMMwTOlV9ehSYhP2u2OD8VVgr7AFgrxGFJJjrzRWxquKvulPnYPivn8bKkbuiWf3/ vaWpQelYnhvFuBkfwBetlw8ZH1YUEez3F/WQBOiRrnBa8cipa9cPAgu88jYr0epbDm0r hGOy37mOTUcI6kC1UykXegyswxAZJ3Lq0GbUJIiYJ4xNm2UamHZcltjjj71djJCfjd0p k0Mg== X-Gm-Message-State: APjAAAUJS8v48FyVman/oU1U6z5QkIWRmO2UYDEmAOSE5S6JCHn+W6Vw U+H3Q0noUCeSeFj43Z27OeIUpw== X-Google-Smtp-Source: APXvYqyh4/B+y5Lf+Lfk4HdOTVWT/2Awv4SRzSG/urGvGWOvhpdahEasiW01kKZGNmwbPY01L+UzvQ== X-Received: by 2002:a17:902:6a83:: with SMTP id n3mr77206034plk.109.1558367622948; Mon, 20 May 2019 08:53:42 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id f5sm19798150pfn.161.2019.05.20.08.53.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 May 2019 08:53:42 -0700 (PDT) Date: Mon, 20 May 2019 08:53:40 -0700 From: Stephen Hemminger To: Jiri Pirko Cc: netdev@vger.kernel.org, davem@davemloft.net, xdp-newbies@vger.kernel.org, bpf@vger.kernel.org, Stephen Hemminger , Jason Wang Subject: Re: [PATCH v2 net 2/2] net: core: generic XDP support for stacked device Message-ID: <20190520085340.4f44ac8b@hermes.lan> In-Reply-To: <20190520091105.GA2142@nanopsycho> 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=US-ASCII Content-Transfer-Encoding: 7bit Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, 20 May 2019 11:11:05 +0200 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 > >--- > 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). > > The reason for troubles was often fact that different flows were treated > differently (vlan accel/non-accel). Yes, this is a sensitive path. Another alternative is to fix it inside each device (netvsc). That is what my earlier patch did and that is what is being done now (probably will make it into the RHEL on Azure drivers). > 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()? > That could work, but has the question about doing XDP farther down call stack (lower performance). There is also the case what if both paths support XDP in driver. This would be the ideal case, how would this work?