From: Horatiu Vultur <horatiu.vultur@microchip.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, <roopa@cumulusnetworks.com>,
<nikolay@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 1/3] net: Add HW_BRIDGE offload feature
Date: Sun, 25 Aug 2019 12:44:15 +0200 [thread overview]
Message-ID: <20190825104413.ftnarx46hhym632w@soft-dev3.microsemi.net> (raw)
In-Reply-To: <afde1b82-2e4c-5b93-ff31-83cb80a0f7bd@gmail.com>
The 08/23/2019 16:30, Florian Fainelli wrote:
> External E-Mail
>
>
> On 8/23/19 5:39 AM, Horatiu Vultur wrote:
> > The 08/22/2019 22:08, Andrew Lunn wrote:
> >> External E-Mail
> >>
> >>
> >>> +/* Determin if the SW bridge can be offloaded to HW. Return true if all
> >>> + * the interfaces of the bridge have the feature NETIF_F_HW_SWITCHDEV set
> >>> + * and have the same netdev_ops.
> >>> + */
> >>
> >> Hi Horatiu
> >>
> >> Why do you need these restrictions. The HW bridge should be able to
> >> learn that a destination MAC address can be reached via the SW
> >> bridge. The software bridge can then forward it out the correct
> >> interface.
> >>
> >> Or are you saying your hardware cannot learn from frames which come
> >> from the CPU?
> >>
> >> Andrew
> >>
> > Hi Andrew,
> >
> > I do not believe that our HW can learn from frames which comes from the
> > CPU, at least not in the way they are injected today. But in case of Ocelot
> > (and the next chip we are working on), we have other issues in mixing with
> > foreign interfaces which is why we have the check in
> > ocelot_netdevice_dev_check.
> >
> > More important, as we responded to Nikolay, we properly introduced this
> > restriction for the wrong reasons.
> >
> > In SW bridge I will remove all these restrictions and only set ports in
> > promisc mode only if NETIF_F_HW_BRIDGE is not set.
> > Then in the network driver I can see if a foreign interface is added to
> > the bridge, and when that happens I can set the port in promisc mode.
> > Then the frames will be flooded to the SW bridge which eventually will
> > send to the foreign interface.
>
> Is that really necessary?
From what I see, it seems to be necessary.
> Is not the skb->fwd_offload_mark as well as
> the phys_switch_id supposed to tell that information to the bridge already?
Yes, the bridge is using the fwd_offload_mark to know that it should or
should not forward the frame. But in case that the network driver knows
that the SW bridge will not do anything with the frame, then there is no
point to send the frame to SW bridge just to use CPU cycles for dropping
the frame.
> --
> Florian
--
/Horatiu
next prev parent reply other threads:[~2019-08-25 10:44 UTC|newest]
Thread overview: 18+ 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 ` [PATCH 1/3] net: Add HW_BRIDGE offload feature Horatiu Vultur
2019-08-22 20:08 ` Andrew Lunn
2019-08-23 12:39 ` Horatiu Vultur
2019-08-23 23:30 ` Florian Fainelli
2019-08-25 10:44 ` Horatiu Vultur [this message]
2019-08-22 19:07 ` [PATCH 2/3] net: mscc: Use NETIF_F_HW_BRIDGE Horatiu Vultur
2019-08-22 19:07 ` [PATCH 3/3] net: mscc: Implement promisc mode Horatiu Vultur
2019-08-22 22:09 ` [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature Nikolay Aleksandrov
2019-08-22 22:26 ` Nikolay Aleksandrov
2019-08-23 12:26 ` Horatiu Vultur
2019-08-23 13:25 ` Andrew Lunn
2019-08-23 15:57 ` Horatiu Vultur
2019-08-22 22:32 ` David Miller
2019-08-23 23:25 ` Florian Fainelli
2019-08-24 7:42 ` Jiri Pirko
2019-08-25 16:30 ` Horatiu Vultur
2019-08-24 12:05 ` [Bridge] " 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=20190825104413.ftnarx46hhym632w@soft-dev3.microsemi.net \
--to=horatiu.vultur@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=allan.nielsen@microchip.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome