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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 93039C3A59F for ; Thu, 29 Aug 2019 13:15:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A383215EA for ; Thu, 29 Aug 2019 13:15:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="WbNRVsGD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727873AbfH2NP4 (ORCPT ); Thu, 29 Aug 2019 09:15:56 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:40692 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727109AbfH2NPx (ORCPT ); Thu, 29 Aug 2019 09:15:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jFMdGRkchqnYEBrx24o+aDmbK62nouD4dZcC7gAUcKw=; b=WbNRVsGDr16eD5VFXzibrYWSTw ZUvdxn6w6eSnOtiO9raQPa7u48PVNYr6HKxUr1eMHyoeH+UtrualQdcUrg9o1h04pYW95Ua9WozwZ 0Nns1CYUZhYi+isiGmWoY5LTaDwxJJSVBq3xJfImOiEff9sr/XRFpVp3i4WFewiD2CMk=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1i3KH9-0002EA-FC; Thu, 29 Aug 2019 15:15:43 +0200 Date: Thu, 29 Aug 2019 15:15:43 +0200 From: Andrew Lunn To: Ivan Vecera Cc: Horatiu Vultur , Jiri Pirko , alexandre.belloni@bootlin.com, UNGLinuxDriver@microchip.com, davem@davemloft.net, allan.nielsen@microchip.com, f.fainelli@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity. Message-ID: <20190829131543.GB6998@lunn.ch> References: <1567070549-29255-1-git-send-email-horatiu.vultur@microchip.com> <1567070549-29255-2-git-send-email-horatiu.vultur@microchip.com> <20190829095100.GH2312@nanopsycho> <20190829105650.btgvytgja63sx6wx@soft-dev3.microsemi.net> <20190829121811.GI2312@nanopsycho> <20190829124412.nrlpz5tzx3fkdoiw@soft-dev3.microsemi.net> <20190829145518.393fb99d@ceranb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190829145518.393fb99d@ceranb> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 29, 2019 at 02:55:18PM +0200, Ivan Vecera wrote: > On Thu, 29 Aug 2019 14:44:14 +0200 > Horatiu Vultur wrote: > > > When a port is added to a bridge, then the port gets in promisc mode. > > But in our case the HW has bridge capabilities so it is not required > > to set the port in promisc mode. > > But if someone else requires the port to be in promisc mode (tcpdump > > or any other application) then I would like to set the port in promisc > > mode. > > In previous emails Andrew came with the suggestion to look at > > dev->promiscuity and check if the port is a bridge port. Using this > > information I could see when to add the port in promisc mode. He also > > suggested to add a new switchdev call(maybe I missunderstood him, or I > > have done it at the wrong place) in case there are no callbacks in the > > driver to get this information. > > I would use the 1st suggestion. > > for/in your driver: > if (dev->promiscuity > 0) { > if (dev->promiscuity == 1 && netif_is_bridge_port(dev)) { > /* no need to set promisc mode because promiscuity > * was requested by bridge > */ > ... > } else { > /* need to set promisc mode as someone else requested > * promiscuity > */ > } > } Hi Ivan The problem with this is, the driver only gets called when promisc goes from 0 to !0. So, the port is added to the bridge. Promisc goes 0->1, and the driver gets called. We can evaluate as you said above, and leave the port filtering frames, not forwarding everything. When tcpdump is started, the core does promisc 1->2, but does not call into the driver. Also, currently sending a notification is not unconditional. What this patch adds is an unconditional call into the switchdev driver so it can evaluate the condition above, with every change to the promisc counter. Andrew