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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 5932AC282C3 for ; Tue, 22 Jan 2019 11:39:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1FE7721726 for ; Tue, 22 Jan 2019 11:39:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="Bvy9sf5H" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728243AbfAVLjv (ORCPT ); Tue, 22 Jan 2019 06:39:51 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:41402 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727663AbfAVLjt (ORCPT ); Tue, 22 Jan 2019 06:39:49 -0500 Received: by mail-lj1-f196.google.com with SMTP id k15-v6so20286606ljc.8 for ; Tue, 22 Jan 2019 03:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zVsz82jnsq3DlKTou03CtZgjkpqqjaMo2tUBWlNSfqw=; b=Bvy9sf5HS4AhkOqvudA26JfvWMVOKIbhBSFzkNJ7Qd3GBbcqvHAOyaPqc5bidm2hLZ vdOzyfvpZIIUf9+PdIiy/102GIO9Vo/w2Qg/a7DV0MG6HUh1ymNs9C4dcXM0/62/HXnf spG1jXvFMXzRUsGBlT09s9YY5eVsHa3vP7Cuo= 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:in-reply-to:user-agent; bh=zVsz82jnsq3DlKTou03CtZgjkpqqjaMo2tUBWlNSfqw=; b=oqvZzUInFJmHuUqFYQzBgLZ72g8hhsgM/I8Sd+tSdtzwMTKwm/Lot3y16w97Rmmgxo J89+fyKSxEJVMuFR8mD2lp6S8ghrOiCPVzCPKTEKK9FAa4K6nkw9VZjwcCT+TlaHBBjH VFmxgilGV9yH94vFQAsQahcgcmVN7VYeRey8R2S+Z7KRAheSRweBn1Yfr/xYPh+o0EkO ZRmwLo8fubCwdqIHWIBDEQemZN7qlWJTPyN/Pevpk24K76G6zB+Usv9VY/sLY8v36iBj UXDUadjjiQdVqlK7oSmro9BxByqo3KwAt9k0jeTwNaKjN/+31JWNdaPd8zotIkgPqYoJ 6fDw== X-Gm-Message-State: AJcUukfTstxhOLzaKi0VUp63ykWcINfCA06kKh0ov9gJhK2AzhSJLvXG dmcHD72y7MspMZWPUvvsTeXpqK5u/hE= X-Google-Smtp-Source: ALg8bN5xXRoiINmCbXhgyVN/qvPTF0A7yGGwZQSYR7vjLALYkbn2qJ0DCoGM5DJg9XQGJLwb1dB1/g== X-Received: by 2002:a2e:88cf:: with SMTP id a15-v6mr69232ljk.76.1548157186914; Tue, 22 Jan 2019 03:39:46 -0800 (PST) Received: from khorivan (59-201-94-178.pool.ukrtel.net. [178.94.201.59]) by smtp.gmail.com with ESMTPSA id b128sm2816803lfe.91.2019.01.22.03.39.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 22 Jan 2019 03:39:46 -0800 (PST) Date: Tue, 22 Jan 2019 13:39:44 +0200 From: Ivan Khoronzhuk To: Florian Fainelli Cc: Ido Schimmel , "netdev@vger.kernel.org" , "andrew@lunn.ch" , "vivien.didelot@gmail.com" , "davem@davemloft.net" , Jiri Pirko , "ilias.apalodimas@linaro.org" , "roopa@cumulusnetworks.com" , "nikolay@cumulusnetworks.com" Subject: Re: [PATCH net-next 10/14] net: vlan: Propagate MC addresses with VID through switchdev Message-ID: <20190122113943.GB3125@khorivan> References: <20190116200102.2749-1-f.fainelli@gmail.com> <20190116200102.2749-11-f.fainelli@gmail.com> <20190117144941.GA24079@splinter> <026a9003-63cd-ab28-5e43-819f6fa5c1f8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <026a9003-63cd-ab28-5e43-819f6fa5c1f8@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jan 17, 2019 at 11:12:24AM -0800, Florian Fainelli wrote: >On 1/17/19 6:49 AM, Ido Schimmel wrote: >> On Wed, Jan 16, 2019 at 12:00:58PM -0800, Florian Fainelli wrote: >>> The VLAN real device could be an Ethernet switch port and that switch >>> might have VLAN filtering globally enabled (because of a bridge >>> requesting VLAN filtering on the switch on another port) and so when >>> programming multicast addresses, we need the multicast filter >>> programming to be aware of the correct VLAN ID as well. >> >> This looks like a quirk of a specific device. How bad is it to patch the >> driver to add a multicast address for every configured VLAN? > >There is at least another driver that can be benefit from that which is >cpsw, if I understand Ivan's use case correctly. > >If there is a ndo_set_rx_mode() function implemented by the virtual >device, and that does call dev_{mc,uc}_sync(master, dev), then this >means that you do want to be able to filter UC and MC addresses. If we >added the entire class D range of multicast addresses to the switch's >MDB, that would not be filtering, we would be passing up everything to >the stack and let it filter in software because there is no multicast >socket listening on that address. > >> >> Also, I think it's weird that we have one API to program address and a >> completely different API (via switchdev) to program address+VID pairs. >> Extending current API might make more sense. >> > >Do you mean ndo_set_rx_mode() and dev_mc_sync()? That is what Ivan >proposed doing not so long ago here: > >https://www.spinics.net/lists/netdev/msg537424.html > >but that is IMHO wasting storage space, because the kernel is >maintaining the address lists, and now also needs to gain knowledge >about the VID. With up to 4K - 2 VLAN interfaces per switch port, this >bloats the memory footprint, we arguably still need to maintain those >address lists anyway... > >The reason why I chose switchdev here is because: > >- this is mostly relevant for switch devices, not so much for NICs (it >seems), if it was, they would have solved the problem by now If provide normal interface for this it could spread. And personally my aim is to avoid redundant mcast traffic when i don't expect it saving CPU performance, latency .... and overall it should be done in this way, switchdev here seems like otth. > >- this allows to have an unified path from the switch driver perspective >to program MDB addresses targeting the CPU/management port, no need to >have X different ways of doing the same operation >-- >Florian -- Regards, Ivan Khoronzhuk