From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> To: Horatiu Vultur <horatiu.vultur@microchip.com>, roopa@cumulusnetworks.com, davem@davemloft.net, UNGLinuxDriver@microchip.com, alexandre.belloni@bootlin.com, allan.nielsen@microchip.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org Subject: Re: [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature Date: Fri, 23 Aug 2019 01:26:12 +0300 [thread overview] Message-ID: <b2c52206-82d1-ef28-aeec-a5dcdbe9df6c@cumulusnetworks.com> (raw) In-Reply-To: <1e16da88-08c5-abd5-0a3e-b8e6c3db134a@cumulusnetworks.com> On 8/23/19 1:09 AM, Nikolay Aleksandrov wrote: > On 22/08/2019 22:07, Horatiu Vultur wrote: >> Current implementation of the SW bridge is setting the interfaces in >> promisc mode when they are added to bridge if learning of the frames is >> enabled. >> In case of Ocelot which has HW capabilities to switch frames, it is not >> needed to set the ports in promisc mode because the HW already capable of >> doing that. Therefore add NETIF_F_HW_BRIDGE feature to indicate that the >> HW has bridge capabilities. Therefore the SW bridge doesn't need to set >> the ports in promisc mode to do the switching. >> This optimization takes places only if all the interfaces that are part >> of the bridge have this flag and have the same network driver. >> >> If the bridge interfaces is added in promisc mode then also the ports part >> of the bridge are set in promisc mode. >> >> Horatiu Vultur (3): >> net: Add HW_BRIDGE offload feature >> net: mscc: Use NETIF_F_HW_BRIDGE >> net: mscc: Implement promisc mode. >> >> drivers/net/ethernet/mscc/ocelot.c | 26 ++++++++++++++++++++++++-- >> include/linux/netdev_features.h | 3 +++ >> net/bridge/br_if.c | 29 ++++++++++++++++++++++++++++- >> net/core/ethtool.c | 1 + >> 4 files changed, 56 insertions(+), 3 deletions(-) >> > Just to clarify: > IMO the name is misleading. - that's not mandatory or anything, just saying people might get confused when they see it > Why do the devices have to be from the same driver ? This is too specific targeting some > devices. The bridge should not care what's the port device, it should be the other way That was mostly a rhetorical question, it's obvious why but please add an explanation at least in the commit message and please fix the typos in the comment. Also HW is capable of doing switching, this needs some clarification that the whole process stays in HW IIUC. More details here would be great. > around, so adding device-specific code to the bridge is not ok. Isn't there a solution > where you can use NETDEV_JOIN and handle it all from your driver ? > Would all HW-learned entries be hidden from user-space in this case ? > I.e. isn't there a way to do this without introducing a new feature flag ?
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> To: Horatiu Vultur <horatiu.vultur@microchip.com>, roopa@cumulusnetworks.com, davem@davemloft.net, UNGLinuxDriver@microchip.com, alexandre.belloni@bootlin.com, allan.nielsen@microchip.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org Subject: Re: [Bridge] [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature Date: Fri, 23 Aug 2019 01:26:12 +0300 [thread overview] Message-ID: <b2c52206-82d1-ef28-aeec-a5dcdbe9df6c@cumulusnetworks.com> (raw) In-Reply-To: <1e16da88-08c5-abd5-0a3e-b8e6c3db134a@cumulusnetworks.com> On 8/23/19 1:09 AM, Nikolay Aleksandrov wrote: > On 22/08/2019 22:07, Horatiu Vultur wrote: >> Current implementation of the SW bridge is setting the interfaces in >> promisc mode when they are added to bridge if learning of the frames is >> enabled. >> In case of Ocelot which has HW capabilities to switch frames, it is not >> needed to set the ports in promisc mode because the HW already capable of >> doing that. Therefore add NETIF_F_HW_BRIDGE feature to indicate that the >> HW has bridge capabilities. Therefore the SW bridge doesn't need to set >> the ports in promisc mode to do the switching. >> This optimization takes places only if all the interfaces that are part >> of the bridge have this flag and have the same network driver. >> >> If the bridge interfaces is added in promisc mode then also the ports part >> of the bridge are set in promisc mode. >> >> Horatiu Vultur (3): >> net: Add HW_BRIDGE offload feature >> net: mscc: Use NETIF_F_HW_BRIDGE >> net: mscc: Implement promisc mode. >> >> drivers/net/ethernet/mscc/ocelot.c | 26 ++++++++++++++++++++++++-- >> include/linux/netdev_features.h | 3 +++ >> net/bridge/br_if.c | 29 ++++++++++++++++++++++++++++- >> net/core/ethtool.c | 1 + >> 4 files changed, 56 insertions(+), 3 deletions(-) >> > Just to clarify: > IMO the name is misleading. - that's not mandatory or anything, just saying people might get confused when they see it > Why do the devices have to be from the same driver ? This is too specific targeting some > devices. The bridge should not care what's the port device, it should be the other way That was mostly a rhetorical question, it's obvious why but please add an explanation at least in the commit message and please fix the typos in the comment. Also HW is capable of doing switching, this needs some clarification that the whole process stays in HW IIUC. More details here would be great. > around, so adding device-specific code to the bridge is not ok. Isn't there a solution > where you can use NETDEV_JOIN and handle it all from your driver ? > Would all HW-learned entries be hidden from user-space in this case ? > I.e. isn't there a way to do this without introducing a new feature flag ?
next prev parent reply other threads:[~2019-08-22 22:26 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-22 19:07 [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature Horatiu Vultur 2019-08-22 19:07 ` [Bridge] " Horatiu Vultur 2019-08-22 19:07 ` [PATCH 1/3] net: Add HW_BRIDGE offload feature Horatiu Vultur 2019-08-22 19:07 ` [Bridge] " Horatiu Vultur 2019-08-22 20:08 ` Andrew Lunn 2019-08-22 20:08 ` [Bridge] " Andrew Lunn 2019-08-23 12:39 ` Horatiu Vultur 2019-08-23 12:39 ` [Bridge] " Horatiu Vultur 2019-08-23 23:30 ` Florian Fainelli 2019-08-23 23:30 ` [Bridge] " Florian Fainelli 2019-08-25 10:44 ` Horatiu Vultur 2019-08-25 10:44 ` [Bridge] " Horatiu Vultur 2019-08-22 19:07 ` [PATCH 2/3] net: mscc: Use NETIF_F_HW_BRIDGE Horatiu Vultur 2019-08-22 19:07 ` [Bridge] " Horatiu Vultur 2019-08-22 19:07 ` [PATCH 3/3] net: mscc: Implement promisc mode Horatiu Vultur 2019-08-22 19:07 ` [Bridge] " Horatiu Vultur 2019-08-22 22:09 ` [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature Nikolay Aleksandrov 2019-08-22 22:09 ` [Bridge] " Nikolay Aleksandrov 2019-08-22 22:26 ` Nikolay Aleksandrov [this message] 2019-08-22 22:26 ` Nikolay Aleksandrov 2019-08-23 12:26 ` Horatiu Vultur 2019-08-23 12:26 ` [Bridge] " Horatiu Vultur 2019-08-23 13:25 ` Andrew Lunn 2019-08-23 13:25 ` [Bridge] " Andrew Lunn 2019-08-23 15:57 ` Horatiu Vultur 2019-08-23 15:57 ` [Bridge] " Horatiu Vultur 2019-08-22 22:32 ` David Miller 2019-08-22 22:32 ` [Bridge] " David Miller 2019-08-23 23:25 ` Florian Fainelli 2019-08-23 23:25 ` [Bridge] " Florian Fainelli 2019-08-24 7:42 ` Jiri Pirko 2019-08-25 16:30 ` Horatiu Vultur 2019-08-25 16:30 ` [Bridge] " Horatiu Vultur 2019-08-24 12:05 ` Stephen Hemminger 2019-08-24 12:05 ` Stephen Hemminger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b2c52206-82d1-ef28-aeec-a5dcdbe9df6c@cumulusnetworks.com \ --to=nikolay@cumulusnetworks.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=allan.nielsen@microchip.com \ --cc=bridge@lists.linux-foundation.org \ --cc=davem@davemloft.net \ --cc=horatiu.vultur@microchip.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=roopa@cumulusnetworks.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.