From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolay Aleksandrov Subject: Re: [RFC PATCH] net: bridge: multicast querier per VLAN support Date: Wed, 18 Apr 2018 19:27:43 +0300 Message-ID: <679E3D8F-7491-48CF-B65B-AD95087DB704@cumulusnetworks.com> References: <20180418120713.GA10742@troglobit> <20180418130718.GA16044@troglobit> <20180418085407.4f5723de@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joachim Nilsson , netdev@vger.kernel.org, roopa To: Stephen Hemminger Return-path: Received: from mail-wr0-f181.google.com ([209.85.128.181]:41600 "EHLO mail-wr0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751383AbeDRQ1s (ORCPT ); Wed, 18 Apr 2018 12:27:48 -0400 Received: by mail-wr0-f181.google.com with SMTP id v24-v6so6465835wra.8 for ; Wed, 18 Apr 2018 09:27:48 -0700 (PDT) In-Reply-To: <20180418085407.4f5723de@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: On April 18, 2018 6:54:07 PM GMT+03:00, Stephen Hemminger wrote: >On Wed, 18 Apr 2018 16:14:26 +0300 >Nikolay Aleksandrov wrote: > >> On 18/04/18 16:07, Joachim Nilsson wrote: >> > On Wed, Apr 18, 2018 at 03:31:57PM +0300, Nikolay Aleksandrov >wrote: =20 >> >> On 18/04/18 15:07, Joachim Nilsson wrote: =20 >> >>> - First of all, is this patch useful to anyone =20 >> >> Obviously to us as it's based on our patch=2E :-) >> >> We actually recently discussed what will be needed to make it >acceptable to upstream=2E =20 >> >=20 >> > Great! :) >> > =20 >> >>> - The current br_multicast=2Ec is very complex=2E The support for >both IPv4 >> >>> and IPv6 is a no-brainer, but it also has #ifdef >VLAN_FILTERING and >> >>> 'br->vlan_enabled' =2E=2E=2E this has likely been discussed befo= re, >but if >> >>> we could remove those code paths I believe what's left would >be quite >> >>> a bit easier to read and maintain=2E =20 >> >> br->vlan_enabled has a wrapper that can be used without ifdefs, as >does br_vlan_find() >> >> so in short - you can remove the ifdefs and use the wrappers,=20 >they'll degrade to always >> >> false/null when vlans are disabled=2E =20 >> >=20 >> > Thanks, I'll have a look at that and prepare an RFC v2! >> > =20 >> >>> - Many per-bridge specific multicast sysfs settings may need to >have a >> >>> corresponding per-VLAN setting, e=2Eg=2E snooping, query_interva= l, >etc=2E >> >>> How should we go about that? (For status reporting I have a >proposal) =20 >> >> We'll have to add more to the per-vlan context, but yes it has to >happen=2E >> >> It will be only netlink interface for config/retrieval, no sysfs=2E= =20 > >> >=20 >> > Some settings are possible to do with sysfs, like >multicast_query_interval >> > and =2E=2E=2E =20 >>=20 >> We want to avoid sysfs in general, all of networking config and stats >> are moving to netlink=2E It is better controlled and structured for >such >> changes, also provides nice interfaces for automatic type checks >etc=2E >>=20 >> Also (but a minor reason) there is no tree/entity in sysfs for the >vlans >> where to add this=2E It will either have to be a file which does some >> format string hack (like us currently) or will need to add new tree >for >> them which I'd really like to avoid for the bridge=2E > >In general, all bridge attributes need to show in netlink and sysfs=2E >Sysfs is easier for scripting from languages=2E True, but vlans and per-vlan settings have never been exposed via sysfs, o= nly through netlink=2E I'd like to avoid adding a directory with potentially 4k multiplied by the= attr number for each vlan entries=2E There is already vlan config infrastructure via netlink=2E