[{"id":1776574,"web_url":"http://patchwork.ozlabs.org/comment/1776574/","msgid":"<1c4ba973-91c0-ae81-1c4b-d0281f5c7517@gmail.com>","list_archive_url":null,"date":"2017-09-27T19:46:35","subject":"Re: [PATCH net-next 2/6] net: dsa: {e}dsa: set offload_fwd_mark on\n\treceived packets","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/26/2017 03:25 PM, Andrew Lunn wrote:\n> The software bridge needs to know if a packet has already been bridged\n> by hardware offload to ports in the same hardware offload, in order\n> that it does not re-flood them, causing duplicates. This is\n> particularly true for broadcast and multicast traffic which the host\n> has requested.\n> \n> By setting offload_fwd_mark in the skb the bridge will only flood to\n> ports in other offloads and other netifs. Set this flag in the DSA and\n> EDSA tag driver.\n\nIs not there some kind of forwarding code/reason code being provided in\nthe EDSA/DSA tag that tell you why this packet was sent to the CPU in\nthe first place?\n\nWhat is the impact on non-broadcast traffic, e.g: multicast and unicast?\n\nNit: I don't really have a solution on how to order patches, but until\nthe next 4 patches get in, I suppose we temporarily have broadcast\nflooding by the bridge \"broken\"? Ordering in the opposite way would\nprobably result in an equally bad situation so...\n\n> \n> Signed-off-by: Andrew Lunn \n> ---\n> \n> v2\n> --\n> For the moment, do this in the tag drivers, not the generic code.\n> Once we get more test results from other switches, maybe move it back\n> again.\n> ---\n> net/dsa/tag_dsa.c | 1 +\n> net/dsa/tag_edsa.c | 1 +\n> 2 files changed, 2 insertions(+)\n> \n> diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c\n> index fbf9ca954773..ea6ada9d5016 100644\n> --- a/net/dsa/tag_dsa.c\n> +++ b/net/dsa/tag_dsa.c\n> @@ -154,6 +154,7 @@ static struct sk_buff *dsa_rcv(struct sk_buff *skb, struct net_device *dev,\n> \t}\n> \n> \tskb->dev = ds->ports[source_port].netdev;\n> +\tskb->offload_fwd_mark = 1;\n> \n> \treturn skb;\n> }\n> diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c\n> index 76367ba1b2e2..a961b22a7018 100644\n> --- a/net/dsa/tag_edsa.c\n> +++ b/net/dsa/tag_edsa.c\n> @@ -173,6 +173,7 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,\n> \t}\n> \n> \tskb->dev = ds->ports[source_port].netdev;\n> +\tskb->offload_fwd_mark = 1;\n> \n> \treturn skb;\n> }\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"KzjMq2+O\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2Sxw6lcQz9sRm\n\tfor ;\n\tThu, 28 Sep 2017 05:46:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751436AbdI0Tqm (ORCPT );\n\tWed, 27 Sep 2017 15:46:42 -0400","from mail-wm0-f68.google.com ([74.125.82.68]:45123 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750917AbdI0Tql (ORCPT\n\t); Wed, 27 Sep 2017 15:46:41 -0400","by mail-wm0-f68.google.com with SMTP id q124so22165229wmb.0\n\tfor ; Wed, 27 Sep 2017 12:46:40 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tw18sm8283218wra.61.2017.09.27.12.46.37\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 27 Sep 2017 12:46:38 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=qnwu4cAcb7NQ23ChbAkE3LIY/zdayrG87fIf5zZJa6w=;\n\tb=KzjMq2+OB6dVzqVMeivya7CWYRIIqmMPrjMbxGXXKVqBOXw/MQ9Y4RHioBtD+nh0v5\n\thzr71RMbLpU5atb/ELRfPJGQ9xDfJdzIUrv7GDvJ7aqbHFTZlVPDMIZT5ENOcLvJoIWU\n\t/WBkBsV6zGnaTX1XRSr0X6CbVlkVuwPzyLylIi9HJfXj7ByVgeANhVRaug80zXSzJMWh\n\t6bzQnnd5sCaT+loL40mr0VwbuAS4rhiSCAkA0eKhvrbv5nEBNHcBkYTp0fuCUYEdvg8W\n\tPNbRzTyqrYOByfr10qu8qDb5QlOi6Fgn08cJofhwn72lsRvHbVrVGlyl4rROvdFE0SGQ\n\tH+Hg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=qnwu4cAcb7NQ23ChbAkE3LIY/zdayrG87fIf5zZJa6w=;\n\tb=n3V+Tq1gT1N84OTjOu4Nyl0NPdX4mQONN5+XNeR+Y+k4v7SN2iw+mTwt7OEFJ9Ix+N\n\twZ+UfEWHM1tljWE6+arSXLgvVI2Rrhcd4KkRL3PR/F9rzUkR+F4v6pbcOo6B5g0R3yuu\n\tgfg+ktvrjCnkqSCrlgVMt9qaQpK2CsXlAqsId8LF8W+WgaYs5CFkbvljGe4srArahqmf\n\trPuwcGGCii/tA8XrWxOcz3Cyk0T2p9pqpZmzqNW8JptSA1ESybYQ1neKtpmObcV3hoZo\n\t0JTWaDsjCrYkEp3T1zXFrSZSL7BroDpvPJl6mh7kRsflqQR5u9jFC2VqGxkAOHuk/5FI\n\tnBzA==","X-Gm-Message-State":"AHPjjUiH8+1/EALOR0SwuOzoDaO3Eg13FNC3CZjn9bB8OMdrC5gF9f9S\n\ts0LIhD9GREwklYREaLig+eFmrnCl","X-Google-Smtp-Source":"AOwi7QCe6qdNA2PkK06IG5bUaj0higOhCtD+PSWj3nonEp+6fSarWZ++Ml/DK6b29//ZOA3cno/3RQ==","X-Received":"by 10.28.31.140 with SMTP id f134mr1045718wmf.81.1506541599471; \n\tWed, 27 Sep 2017 12:46:39 -0700 (PDT)","Subject":"Re: [PATCH net-next 2/6] net: dsa: {e}dsa: set offload_fwd_mark on\n\treceived packets","To":"Andrew Lunn , David Miller ","Cc":"Vivien Didelot ,\n\tnetdev ","References":"<1506464764-12699-1-git-send-email-andrew@lunn.ch>\n\t<1506464764-12699-3-git-send-email-andrew@lunn.ch>","From":"Florian Fainelli ","Message-ID":"<1c4ba973-91c0-ae81-1c4b-d0281f5c7517@gmail.com>","Date":"Wed, 27 Sep 2017 12:46:35 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1506464764-12699-3-git-send-email-andrew@lunn.ch>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1776587,"web_url":"http://patchwork.ozlabs.org/comment/1776587/","msgid":"<20170927201120.GG12394@lunn.ch>","list_archive_url":null,"date":"2017-09-27T20:11:20","subject":"Re: [PATCH net-next 2/6] net: dsa: {e}dsa: set offload_fwd_mark on\n\treceived packets","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Wed, Sep 27, 2017 at 12:46:35PM -0700, Florian Fainelli wrote:\n> On 09/26/2017 03:25 PM, Andrew Lunn wrote:\n> > The software bridge needs to know if a packet has already been bridged\n> > by hardware offload to ports in the same hardware offload, in order\n> > that it does not re-flood them, causing duplicates. This is\n> > particularly true for broadcast and multicast traffic which the host\n> > has requested.\n> > \n> > By setting offload_fwd_mark in the skb the bridge will only flood to\n> > ports in other offloads and other netifs. Set this flag in the DSA and\n> > EDSA tag driver.\n> \n> Is not there some kind of forwarding code/reason code being provided in\n> the EDSA/DSA tag that tell you why this packet was sent to the CPU in\n> the first place?\n\nHi Florian\n\nThere are some codes, but nothing specific to broadcast, or ATU\nmisses. I'm also trying to keep the code generic so it could be a\ntemplate for other drivers. Many of the tagging schemes don't provide\na reason code. So i want that any frame that comes from the switch has\nno need to go back to the switch. KISS.\n \n> What is the impact on non-broadcast traffic, e.g: multicast and unicast?\n\nThe bridge uses this flag when flooding. unicast traffic from the\nswitch should not need flooding. Either it is known in the switch and\nhence won't be forwarded to the host, or it is unknown in the switch,\nso it probably is on some other interface.\n\nMy testing with multicast has not shown issues. The switch pushes down\nmdb entries, which causes frames to be replicated out ports. So again,\nthere should not be a need to pass the frame back to the switch. But\nit is possible i missed a corner case or two...\n \n> Nit: I don't really have a solution on how to order patches, but until\n> the next 4 patches get in, I suppose we temporarily have broadcast\n> flooding by the bridge \"broken\"? Ordering in the opposite way would\n> probably result in an equally bad situation so...\n\nYes, it is an issue. I could put this patch last. We then get\nduplication of broadcast...\n\nWhich is the lesser of two evils?\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2TVZ3qF6z9t67\n\tfor ;\n\tThu, 28 Sep 2017 06:11:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751569AbdI0ULZ (ORCPT );\n\tWed, 27 Sep 2017 16:11:25 -0400","from vps0.lunn.ch ([185.16.172.187]:58557 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751136AbdI0ULY (ORCPT );\n\tWed, 27 Sep 2017 16:11:24 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dxIfw-0005Dn-7Y; Wed, 27 Sep 2017 22:11:20 +0200"],"Date":"Wed, 27 Sep 2017 22:11:20 +0200","From":"Andrew Lunn ","To":"Florian Fainelli ","Cc":"David Miller ,\n\tVivien Didelot ,\n\tnetdev ","Subject":"Re: [PATCH net-next 2/6] net: dsa: {e}dsa: set offload_fwd_mark on\n\treceived packets","Message-ID":"<20170927201120.GG12394@lunn.ch>","References":"<1506464764-12699-1-git-send-email-andrew@lunn.ch>\n\t<1506464764-12699-3-git-send-email-andrew@lunn.ch>\n\t<1c4ba973-91c0-ae81-1c4b-d0281f5c7517@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1c4ba973-91c0-ae81-1c4b-d0281f5c7517@gmail.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]