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=-5.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 850A7C388F9 for ; Wed, 11 Nov 2020 04:12:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C74B20797 for ; Wed, 11 Nov 2020 04:12:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ib95Og1V" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725929AbgKKEMj (ORCPT ); Tue, 10 Nov 2020 23:12:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725849AbgKKEMg (ORCPT ); Tue, 10 Nov 2020 23:12:36 -0500 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A40B7C0613D1 for ; Tue, 10 Nov 2020 20:12:36 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id y7so807033pfq.11 for ; Tue, 10 Nov 2020 20:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2k6URzCfzzpL9VJdHAKuWPN+KAqMKyOJiRf2pxtrQd0=; b=ib95Og1V7CTvfY5ePmvuF6Ekpk+c1E2iu4D/b9g0tzYgajzlFA/xBWH+/tF13+WVb3 MHa8d4tArf6c7HmSP6RWl3HDIsoOKqRfyrQJOdfFkyJzAMQkXzc+7Q8sTplCmEnTcsnE esYRRPCeyI3yL17pJ4HeneUCkg5sTbA575j9Amz+YUp9DKDjY7zxDWsTG4qGbtsEmEWj drGuMriBLRAjfalAupzaCBKAWyPM0RzVzZ9LriVNGGeAYpRzIY2lTUX+tTRyno28dofj 8EJDobtMIQ9LH/DgjuZXzGZEBPuLZirhyn1krB5ec8frmwlbZBb4m8ktnoIxqHkUCZ6W lnDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2k6URzCfzzpL9VJdHAKuWPN+KAqMKyOJiRf2pxtrQd0=; b=ozh+F4GiCxUj71SOBcb46ZXRw1UfWL5bzNDwRqP4Djx26AGwpkw1OC4iR82m5HzCvJ VYVC2OWNfk+mheLwuSPYeDWaEA7JsDamfmgw0o3DQ/9rhpFRhthNGXld/re7VPMAwEAr Kfoef5Xrt3LfxDmHRWejncBxxtDGe9GVQds2ZXkWJG3KpV3xQQzOcRDtPpvGoz76pcgb FEsk5wr5akQlGsRf8+5MN+rzH73AtxYXIeO6suJ8ekzCfB42uZ/6338uhoCWuIgQlLZO 7SZnnQIRP+NKmvYk+lPkOlMDWLNz0Qmm+LtIofLV3pWo7iHHYKI2xATn8UYV2puflxUj u0hw== X-Gm-Message-State: AOAM531FNfupLvEA4Sey/w0ER6fRgcKMlJcB/G0bnXs3Oqerpu9Mdfua 62+iKQw0ET6d+jEq3DoDcH0= X-Google-Smtp-Source: ABdhPJyghvBknt10Ae+O3c9GJYH/njd/pbrxEFOrjOONXDo+mDIGwCjsnicIUpBnmzWAONBIDPd82A== X-Received: by 2002:a62:f252:0:b029:18a:deaf:37d0 with SMTP id y18-20020a62f2520000b029018adeaf37d0mr21148247pfl.48.1605067955978; Tue, 10 Nov 2020 20:12:35 -0800 (PST) Received: from [192.168.1.3] (ip68-111-84-250.oc.oc.cox.net. [68.111.84.250]) by smtp.gmail.com with ESMTPSA id i10sm628537pjz.44.2020.11.10.20.12.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Nov 2020 20:12:34 -0800 (PST) Subject: Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches To: Vladimir Oltean , Ido Schimmel Cc: Andrew Lunn , Vivien Didelot , "David S. Miller" , Jiri Pirko , Jakub Kicinski , Ivan Vecera , vyasevich@gmail.com, netdev , UNGLinuxDriver@microchip.com, Nikolay Aleksandrov , Roopa Prabhu References: <20200720100037.vsb4kqcgytyacyhz@skbuf> <20200727165638.GA1910935@shredder> <20201027115249.hghcrzomx7oknmoq@skbuf> <20201028144338.GA487915@shredder> <20201028184644.p6zm4apo7v4g2xqn@skbuf> <20201101112731.GA698347@shredder> <20201101120644.c23mfjty562t5xue@skbuf> <20201101144217.GA714146@shredder> <20201101150442.as7qfa2qh7figmsn@skbuf> <20201101153906.GA720451@shredder> <20201101161308.qt3i72e37qydtpwz@skbuf> From: Florian Fainelli Message-ID: Date: Tue, 10 Nov 2020 20:12:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <20201101161308.qt3i72e37qydtpwz@skbuf> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 11/1/2020 8:13 AM, Vladimir Oltean wrote: > On Sun, Nov 01, 2020 at 05:39:06PM +0200, Ido Schimmel wrote: >> You also wondered which indication you would get down to the driver that >> eventually needs to program the hardware to get the packets: >> >> "Who will notify me of these multicast addresses if I'm bridged and I >> need to terminate L2 or L4 PTP through the data path of the slave >> interfaces and not of the bridge." >> >> Which kernel entity you want to get the notification from? The packet >> socket wants the packets, so it should notify you. The kernel is aware >> that traffic is offloaded and can do whatever it needs (e.g., calling >> the ndo) in order to extract packets from the hardware data path to the >> CPU and to the socket. > > Honestly, just as I was saying, I was thinking about using the > dev_mc_add call that is emitted today, and simply auditing the > dev_mc_add and dev_uc_add calls which are unnecessary (like in the case > of non-automatic bridge interfaces), for example like this: > > if (!(dev->features & NETIF_F_PROMISC_BY_DEFAULT)) > dev_uc_add(dev, static bridge fdb entry); > > To me this would be the least painful way forward. Vladimir, what do you think about re-posting this series with the DSA ports operating in standalone or bridge mode with the bridge being multicast aware, and tackle the termination of PTP frames on DSA ports being bridged separately? >From what I could read there does not appear to be a problem with doing RX filtering for standalone ports since we all agree that these net_device should look like a regular NIC port with RX filtering capability. -- Florian