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, URIBL_BLOCKED,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 D335EC282C3 for ; Tue, 22 Jan 2019 11:30:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A14B720879 for ; Tue, 22 Jan 2019 11:30:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="YfxOnxMy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727946AbfAVLa4 (ORCPT ); Tue, 22 Jan 2019 06:30:56 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:37942 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727919AbfAVLa4 (ORCPT ); Tue, 22 Jan 2019 06:30:56 -0500 Received: by mail-lf1-f68.google.com with SMTP id a8so17806639lfk.5 for ; Tue, 22 Jan 2019 03:30:54 -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=ZRxGJh3LaO/vX1HEw02HI+TydpZTwlESInOE8UjUhic=; b=YfxOnxMyKUAzgWYfngGciGmI4r5LqmMtk3apvQBXmqJaJ7gGGyRhl4uxCEnCRd0vlt YQIEk6pHBPYtEePAx/5/5HxbLyhieU4ToMZhoCNuTCxufJK21s5UBxdGeKx3ik0by9jU tA3Wh3rU/mlIVfT/5q6mth0NH0pFmuqnV4nyY= 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=ZRxGJh3LaO/vX1HEw02HI+TydpZTwlESInOE8UjUhic=; b=Gg2Mwer4x9eLYKG+2b8RaoJmS940uld9WAUJOjynMs4EUbEEQfSBBmjDiMglP/b3tG L4b7oaATd/NsGljsIVf8u+qJ6HiHCNYJAZUrVEgjgn2FDzBYKENtHTZ9z603q5adlknN 9C66/8+HNNnV/SXevVS4gtNuuUjzq2RmzCo9Z1O4MJ1VJhPsokHcIyHyjN1a8+ADWiSQ cvkpzo608Kl+GEjz1Pf/dhgNz9RhsnGBMKsnS9VOLdGiwhgiYib3FHDs8G/xvkxs/Qa2 3eB10VN+4BtdihEZ3Y4qFs4CFo4Yh3hOkpV+RoYcLiKU+NetHOu1LsF3g0Ezvjpfjhbs OloQ== X-Gm-Message-State: AJcUukcZqfErIi3Vd+qZD2J+KISXXg/jR5ELd9CGEO6nV94YH6tqaOcw PHge6XiPHW4NzQDF1gevXQS08Q== X-Google-Smtp-Source: ALg8bN7ugQJQk66V6ai3tF9HEylMWVlq2JwxpS/NpUr1DvmTfdEbRkiePUtn0Qx+39QBZSp/TMyw4Q== X-Received: by 2002:a19:c014:: with SMTP id q20mr19162707lff.16.1548156653124; Tue, 22 Jan 2019 03:30:53 -0800 (PST) Received: from khorivan (59-201-94-178.pool.ukrtel.net. [178.94.201.59]) by smtp.gmail.com with ESMTPSA id y1-v6sm2788831ljh.39.2019.01.22.03.30.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 22 Jan 2019 03:30:53 -0800 (PST) Date: Tue, 22 Jan 2019 13:30:50 +0200 From: Ivan Khoronzhuk To: Ido Schimmel Cc: Florian Fainelli , "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: <20190122113049.GA3125@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> <20190121091259.GB10994@splinter> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20190121091259.GB10994@splinter> 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 Mon, Jan 21, 2019 at 09:13:01AM +0000, Ido Schimmel wrote: >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. > >I understand and I have no argument against the need for this. I just >think we should use a different mechanism than switchdev. > >> 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. > >OK. > >> > 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... Yes wasting storage it's a factor, even it brings a lot of other benefits. But compared to this it's more legal. As alternative I've also proposed completely working model when vlan identification is real dev responsibility, allowing to split address space between vlans (for mc and uc). And better to add more commments to the referencies I provided there. > >I didn't review Ivan's changes in details, but it makes much more sense >to me to simply extend the current Rx filtering mechanism than to use a >completely unrelated infrastructure. True. > >> >> 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 > >I don't see any use of switchdev APIs in the driver Ivan is patching. >The cover letter doesn't indicate anything about it either. Yes, it's not related to switched. > >> - 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 > >But it's not the same thing. Allowing certain packets to ingress the >device is not the same as having the device send them to the CPU. We >have VLAN filters as well. Allowing VID X to ingress does not mean that >we trap each packet with this VID to CPU. -- Regards, Ivan Khoronzhuk