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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 1A511C282DB for ; Mon, 21 Jan 2019 09:13:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CD2AA2085A for ; Mon, 21 Jan 2019 09:13:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="qF2Wv7HC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726843AbfAUJNK (ORCPT ); Mon, 21 Jan 2019 04:13:10 -0500 Received: from mail-eopbgr70054.outbound.protection.outlook.com ([40.107.7.54]:60864 "EHLO EUR04-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726030AbfAUJNK (ORCPT ); Mon, 21 Jan 2019 04:13:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cvs6IyANM18B2vhsD/W6jcakC5VDLCGLSfoRdSrszAE=; b=qF2Wv7HC/1i3mYHz6rZbVuF+SfmgWBw6k0sgQ3DmYq6IPpB6xYIF+PPJbUkyHt/CnCSLQGd9XRCUo9lbxM324ZSsVt4Dsb2ZRVBpPGfwjJuVX5HqYxdtm8usq6ougNLGszaKo+TDRdqnpoNWgod42HJBVGOQOwAIfv5og4qEjbw= Received: from AM6PR05MB6056.eurprd05.prod.outlook.com (20.179.2.148) by AM6PR05MB6421.eurprd05.prod.outlook.com (20.179.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.26; Mon, 21 Jan 2019 09:13:01 +0000 Received: from AM6PR05MB6056.eurprd05.prod.outlook.com ([fe80::3411:612a:f48b:a5e2]) by AM6PR05MB6056.eurprd05.prod.outlook.com ([fe80::3411:612a:f48b:a5e2%5]) with mapi id 15.20.1537.031; Mon, 21 Jan 2019 09:13:01 +0000 From: Ido Schimmel To: Florian Fainelli CC: "netdev@vger.kernel.org" , "andrew@lunn.ch" , "vivien.didelot@gmail.com" , "davem@davemloft.net" , Jiri Pirko , "ilias.apalodimas@linaro.org" , "ivan.khoronzhuk@linaro.org" , "roopa@cumulusnetworks.com" , "nikolay@cumulusnetworks.com" Subject: Re: [PATCH net-next 10/14] net: vlan: Propagate MC addresses with VID through switchdev Thread-Topic: [PATCH net-next 10/14] net: vlan: Propagate MC addresses with VID through switchdev Thread-Index: AQHUrdaTXmL4bqdifEuajacSaqxn6KWzjBOAgABq7gCABYBTgA== Date: Mon, 21 Jan 2019 09:13:01 +0000 Message-ID: <20190121091259.GB10994@splinter> 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> In-Reply-To: <026a9003-63cd-ab28-5e43-819f6fa5c1f8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6P192CA0047.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:82::24) To AM6PR05MB6056.eurprd05.prod.outlook.com (2603:10a6:20b:ab::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=idosch@mellanox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM6PR05MB6421;6:XR3XOyxbHPlNkkX4deswnVkPI1X1+xIBhPdwXzHT8m+SwBYfa7NAbrtBG4vWU9DhzeNiQe3e5SPWtmzGGUP148uWed8m5sA0JiiR++FWAiev1VPGTme4agBiEAhIsESu77Qyo4efoFAsN6J0d8YZuB/CiAzZiKm7QIfvQy4TmZosMu0at9LY9dLvMytlXnIlu5FtuRe1GgwtFlxrf1qM4Z9v3cDf3DMiehLq3kz9FBTspdVYtYM7FpMzz0tb9WJy65GGEm998TLdXYGGJcVieNeMjKI22RFyRqsh5uudHvmkk6PSjPIhTn20HKab5MFBq0TEBviLdz1i4/WA1da/52LHpluclxwwWZZC0nQ2dg01URvInh6BOxcWbZFD3Mm6jBv5AwYNkX/22oVxidvxMbJlIhiH8vbuIe0buGDnUaDfrDoyCp9B2RbOEjWBhruUxzKKBpzcBtjEu+6U/JjzTw==;5:9p1VzcvjQkOUoiONuvTuFKl68WZjkCa+Xv/Jeo9PnKud+y2Vmtl6ThVhbVzEuk1ajVEA9NoJzh6RJuP9i0REPWcG36HsSii9mSkom3b5xaxsGNrASnGnkWfmP7ug2YupFdE5daR9nwxCgYJ6w/WZANStuGjr+AUEViHTfXcdr9FYwdY4dVwqpEkrJD9PZXQBE1Rg0NFCc4CQ4owyEsSKmg==;7:YEhGCX2ZWFVss27wXquHgnmTQzEqhcZ2CpL8YzBOmjbOvvmR/SLB1q856DUnp77uv0tcEAEuQSQG72QBHyohklY2Ek3WSGmPljFN1OofjZr9qjT9PHN3PpV8OpHIdsykzrK76auno839I4pdSuSVgg== x-ms-office365-filtering-correlation-id: 8842c08e-699a-4dba-4a8f-08d67f80a48e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020);SRVR:AM6PR05MB6421; x-ms-traffictypediagnostic: AM6PR05MB6421: x-microsoft-antispam-prvs: x-forefront-prvs: 0924C6A0D5 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(979002)(7916004)(366004)(136003)(39860400002)(376002)(346002)(396003)(199004)(189003)(97736004)(6306002)(476003)(26005)(6512007)(9686003)(1076003)(102836004)(99286004)(2906002)(6486002)(6436002)(105586002)(106356001)(316002)(66066001)(53936002)(8676002)(33656002)(81166006)(81156014)(25786009)(14454004)(6246003)(186003)(229853002)(39060400002)(8936002)(14444005)(486006)(4326008)(53546011)(33896004)(6916009)(52116002)(256004)(93886005)(305945005)(3846002)(6116002)(446003)(86362001)(68736007)(71200400001)(11346002)(478600001)(386003)(54906003)(7736002)(76176011)(6506007)(966005)(33716001)(71190400001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM6PR05MB6421;H:AM6PR05MB6056.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GP8b50cO/Zef5E+ORrBGHOImyQ1XXK4so+zu9I8PiYQ3vXZaTDTA14jrqU7Fs2BiDrA9FYnVDOdDzI6itfm79meGqy0Tyo7waVAnVR1/5D5F2vydn715+KMja/2dugLVybKDnOYo8fSzWO+RXdgGf46pWTfPauskrVL1tT7gXl6hNHhsH5kM5ZP1+uAQMMKDjdhICDnPSKem8MyWxoV+ooibDzqeT45jGRO8j76DZC6Nx4e5ztD0q9NJHufhmA/KRcRLpaRPsp5d1jyn3mVTsBRfHqOsvdrnDaQ2eFlASr6gvtPVrZ4ufTsFWCS3sNk3H4tStwGQewHiH7MB1QZ4sIXs1cXvOhIb4GUH/Jt25TEODEuv7J3a4w8oWo6JL+r3gLyKcDSYNm8ES7GQrOIpGJljfrMsH2mbE0pL3ez7zPM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <548DA88B4513FD4D96C88DCEE00DAC49@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8842c08e-699a-4dba-4a8f-08d67f80a48e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2019 09:13:01.0802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB6421 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. > >=20 > > This looks like a quirk of a specific device. How bad is it to patch th= e > > driver to add a multicast address for every configured VLAN? >=20 > 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. > >=20 >=20 > Do you mean ndo_set_rx_mode() and dev_mc_sync()? That is what Ivan > proposed doing not so long ago here: >=20 > https://www.spinics.net/lists/netdev/msg537424.html >=20 > 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... 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. >=20 > The reason why I chose switchdev here is because: >=20 > - 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. > - 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.