From: Florian Fainelli <f.fainelli@gmail.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>,
Andrew Lunn <andrew@lunn.ch>
Cc: alexandre.belloni@bootlin.com, nikolay@cumulusnetworks.com,
netdev@vger.kernel.org, roopa@cumulusnetworks.com,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
UNGLinuxDriver@microchip.com, allan.nielsen@microchip.com,
davem@davemloft.net
Subject: Re: [Bridge] [PATCH 1/3] net: Add HW_BRIDGE offload feature
Date: Fri, 23 Aug 2019 16:30:40 -0700 [thread overview]
Message-ID: <afde1b82-2e4c-5b93-ff31-83cb80a0f7bd@gmail.com> (raw)
In-Reply-To: <20190823123929.ta4ikozz7jwkwbo2@soft-dev3.microsemi.net>
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? Is not the skb->fwd_offload_mark as well as
the phys_switch_id supposed to tell that information to the bridge already?
--
Florian
next prev parent reply other threads:[~2019-08-23 23:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 19:07 [Bridge] [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature Horatiu Vultur
2019-08-22 19:07 ` [Bridge] [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 [this message]
2019-08-25 10:44 ` Horatiu Vultur
2019-08-22 19:07 ` [Bridge] [PATCH 2/3] net: mscc: Use NETIF_F_HW_BRIDGE Horatiu Vultur
2019-08-22 19:07 ` [Bridge] [PATCH 3/3] net: mscc: Implement promisc mode Horatiu Vultur
2019-08-22 22:09 ` [Bridge] [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
[not found] ` <20190824074204.GA15041@nanopsycho.orion>
2019-08-25 16:30 ` Horatiu Vultur
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=afde1b82-2e4c-5b93-ff31-83cb80a0f7bd@gmail.com \
--to=f.fainelli@gmail.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=horatiu.vultur@microchip.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