From: Florian Fainelli <f.fainelli@gmail.com>
To: Lukasz Majewski <lukma@denx.de>, Vladimir Oltean <olteanv@gmail.com>
Cc: Fugang Duan <fugang.duan@nxp.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
Fabio Estevam <festevam@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>,
stefan.agner@toradex.com, krzk@kernel.org,
Shawn Guo <shawnguo@kernel.org>
Subject: Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
Date: Fri, 27 Nov 2020 20:34:55 -0800 [thread overview]
Message-ID: <61fc64a6-a02b-3806-49fa-a916c6d9581a@gmail.com> (raw)
In-Reply-To: <20201128013310.38ecf9c7@jawa>
On 11/27/2020 4:33 PM, Lukasz Majewski wrote:
>> So why use DSA at all? What benefit does it bring you? Why not do the
>> entire switch configuration from within FEC, or a separate driver very
>> closely related to it?
>
> Mine rationale to use DSA and FEC:
> - Make as little changes to FEC as possible
Which is entirely possible if you stick to Vladimir suggestions of
exporting services for the MTIP switch driver.
>
> - Provide separate driver to allow programming FDB, MDB, VLAN setup.
> This seems straightforward as MTIP has separate memory region (from
> FEC) for switch configuration, statistics, learning, static table
> programming. What is even more bizarre FEC and MTIP have the same 8
> registers (with different base address and +4 offset :-) ) as
> interface to handle DMA0 transfers.
OK, not sure how that is relevant here? The register organization should
never ever dictate how to pick a particular subsystem.
>
> - According to MTIP description from NXP documentation, there is a
> separate register for frame forwarding, so it _shall_ also fit into
> DSA.
And yet it does not, Vladimir went into great length into explaining
what makes the MTIP + dual FEC different here and why it does not
qualify for DSA. Basically any time you have DMA + integrated switch
tightly coupled you have what we have coined a "pure switchdev" wrapper.
>
>
> For me it would be enough to have:
>
> - lan{12} - so I could enable/disable it on demand (control when switch
> ports are passing or not packets).
>
> - Use standard net tools (like bridge) to setup FDB/MDB, vlan
>
> - Read statistics from MTIP ports (all of them)
>
> - I can use lan1 (bridged or not) to send data outside. It would be
> also correct to use eth0.
You know you can do that without having DSA, right? Look at mlxsw, look
at rocker. You can call multiple times register_netdevice() with custom
network devices that behave differently whether HW bridging offload is
offered or not, whether the switch is declared in Device Tree or not.
>
> I'm for the most pragmatic (and simple) solution, which fulfill above
> requirements.
The most pragmatic solution is to implement switchdev operations to
offer HW bridging offload, VLAN programming, FDB/MDB programming.
It seems to me that you are trying to look for a framework to avoid
doing a bit of middle layer work between switchdev and the FEC driver
and that is not setting you for success.
--
Florian
next prev parent reply other threads:[~2020-11-28 4:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 23:24 [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC Lukasz Majewski
2020-11-25 23:24 ` [RFC 1/4] net: fec: Move some defines to ./drivers/net/ethernet/freescale/fec.h header Lukasz Majewski
2020-11-25 23:24 ` [RFC 2/4] net: dsa: Provide DSA driver for NXP's More Than IP L2 switch Lukasz Majewski
2020-11-25 23:24 ` [RFC 3/4] net: imx: l2switch: Adjust fec_main.c to provide support for " Lukasz Majewski
2020-11-25 23:24 ` [RFC 4/4] ARM: dts: imx28: Add description for L2 switch on XEA board Lukasz Majewski
2020-11-26 0:00 ` [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC Andrew Lunn
2020-11-26 1:30 ` Florian Fainelli
2020-11-26 3:10 ` Andrew Lunn
2020-11-26 10:10 ` Lukasz Majewski
2020-11-26 14:45 ` Andrew Lunn
2020-11-27 0:03 ` Lukasz Majewski
2020-11-26 12:30 ` Vladimir Oltean
2020-11-26 23:35 ` Lukasz Majewski
2020-11-27 0:55 ` Andrew Lunn
2020-11-27 9:16 ` Lukasz Majewski
2020-11-27 1:08 ` Andrew Lunn
2020-11-27 9:25 ` Lukasz Majewski
2020-11-27 15:10 ` Andrew Lunn
2021-06-17 11:08 ` Lukasz Majewski
2021-06-17 13:57 ` Andrew Lunn
2020-11-27 19:29 ` Vladimir Oltean
2020-11-28 0:33 ` Lukasz Majewski
2020-11-28 4:34 ` Florian Fainelli [this message]
2020-11-29 21:59 ` Lukasz Majewski
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=61fc64a6-a02b-3806-49fa-a916c6d9581a@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=festevam@gmail.com \
--cc=fugang.duan@nxp.com \
--cc=krzk@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukma@denx.de \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=peng.fan@nxp.com \
--cc=shawnguo@kernel.org \
--cc=stefan.agner@toradex.com \
--cc=vivien.didelot@gmail.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;
as well as URLs for NNTP newsgroup(s).