From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
Oleksij Rempel <linux@rempel-privat.de>,
netdev@vger.kernel.org, andrew@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, nbd@nbd.name, sean.wang@mediatek.com,
Mark-MC.Lee@mediatek.com, lorenzo.bianconi83@gmail.com
Subject: Re: [RFC net-next 0/5] Add ETS and TBF Qdisc offload for Airoha EN7581 SoC
Date: Tue, 17 Dec 2024 11:01:28 +0100 [thread overview]
Message-ID: <Z2FL-IcDLHXV-WCU@lore-desk> (raw)
In-Reply-To: <20241217093040.x4yangwss2xa5lbz@skbuf>
[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]
> On Tue, Dec 17, 2024 at 10:11:46AM +0100, Lorenzo Bianconi wrote:
> > > When you add an offloaded Qdisc to the egress of lan1, the expectation
> > > is that packets from lan2 obey it too (offloaded tc goes hand in hand
> > > with offloaded bridge). Whereas, by using GDM1/QDMA resources, you are
> > > breaking that expectation, because packets from lan2 bridged by MT7530
> > > don't go to GDM1 (the "x").
> >
> > ack, I got your point. I was assuming to cover this case (traffic from lan2 to
> > lan1) maintaining the port_setup_tc() callback in dsa_user_setup_qdisc() (this
> > traffic is not managed by ndo_setup_tc_conduit() callback). If this approach is
> > not ok, I guess we will need to revisit the approach.
>
> To offload QoS on the egress of a DSA user port:
>
> port_setup_tc() is:
> (a) necessary
> (b) sufficient
>
> ndo_setup_tc_conduit() is:
> (a) unnecessary
I agree it is unnecessary, but w/o it we must rely on limited QoS capabilities
of the hw dsa switch. The goal of the series is just exploit enhanced QoS
capabilities available on the EN7581 SoC.
> (b) insufficient
>
> > > But you call it a MAC chip because between the GDM1 and the MT7530 there's
> > > an in-chip Ethernet MAC (GMII netlist), with a fixed packet rate, right?
> >
> > With "mac chip" I mean the set of PSE/PPE and QDMA blocks in the diagram
> > (what is managed by airoha_eth driver). There is no other chip in between
> > of GDM1 and MT7530 switch (sorry for the confusion).
>
> The MT7530 is also on the same chip as the GDM1, correct?
I think so, but I am not sure.
>
> > > I'm asking again, are the channels completely independent of one another,
> > > or are they consuming shared bandwidth in a way that with your proposal
> > > is just not visible? If there is a GMII between the GDM1 and the MT7530,
> > > how come the bandwidth between the channels is not shared in any way?
> >
> > Channels are logically independent.
>
> "Logically independent" does not mean "does not share resources", which
> is what I asked.
>
> > GDM1 is connected to the MT7530 switch via a fixed speed link (10Gbps, similar
> > to what we have for other MediaTek chipset, like MT7988 [0]). The fixed link speed
> > is higher than the sum of DSA port link speeds (on my development boards I have
> > 4 DSA ports @ 1Gbps);
>
> And this fixed connection is a pair of internal Ethernet MACs, correct?
yes
> I see on MT7988 we do have the "pause" property, which would suggest so,
> since flow control is a MAC level feature. I assume 10 Gbps in the
> device tree means it is an XGMII really limited at that speed, and that
> speed is not just for phylink compliance, right?
I think so
>
> What if we push your example to the extreme, and say that the DSA user
> ports also have 10 Gbps links? How independent are the QDMA channels in
> this case? What arbitration algorithm will be used for QoS among user
> ports, when the combined bandwidth exceeds the CPU port capacity?
AFIR there is even the possibility to configure inter-channel QoS on the chip,
like a Round Robin scheduler or Strict-Priority between channels.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-12-17 10:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 15:31 [RFC net-next 0/5] Add ETS and TBF Qdisc offload for Airoha EN7581 SoC Lorenzo Bianconi
2024-12-11 15:31 ` [RFC net-next 1/5] net: airoha: Enable Tx drop capability for each Tx DMA ring Lorenzo Bianconi
2024-12-11 15:31 ` [RFC net-next 2/5] net: airoha: Introduce ndo_select_queue callback Lorenzo Bianconi
2024-12-11 15:31 ` [RFC net-next 3/5] net: dsa: Introduce ndo_setup_tc_conduit callback Lorenzo Bianconi
2024-12-11 15:31 ` [RFC net-next 4/5] net: airoha: Add sched ETS offload support Lorenzo Bianconi
2024-12-12 14:37 ` Davide Caratti
2024-12-12 17:04 ` Lorenzo Bianconi
2024-12-11 15:31 ` [RFC net-next 5/5] net: airoha: Add sched TBF " Lorenzo Bianconi
2024-12-11 15:41 ` [RFC net-next 0/5] Add ETS and TBF Qdisc offload for Airoha EN7581 SoC Vladimir Oltean
2024-12-12 9:19 ` Lorenzo Bianconi
2024-12-12 15:06 ` Vladimir Oltean
2024-12-12 17:03 ` Lorenzo Bianconi
2024-12-12 18:46 ` Vladimir Oltean
2024-12-16 12:09 ` Lorenzo Bianconi
2024-12-16 15:49 ` Vladimir Oltean
2024-12-16 18:14 ` Oleksij Rempel
2024-12-16 19:01 ` Lorenzo Bianconi
2024-12-16 19:23 ` Oleksij Rempel
2024-12-16 21:44 ` Lorenzo Bianconi
2024-12-17 8:46 ` Oleksij Rempel
2024-12-16 19:46 ` Vladimir Oltean
2024-12-16 22:28 ` Lorenzo Bianconi
2024-12-16 23:13 ` Vladimir Oltean
2024-12-17 9:11 ` Lorenzo Bianconi
2024-12-17 9:30 ` Vladimir Oltean
2024-12-17 10:01 ` Lorenzo Bianconi [this message]
2024-12-17 10:17 ` Vladimir Oltean
2024-12-17 10:23 ` Oleksij Rempel
2024-12-16 23:24 ` Andrew Lunn
2024-12-17 9:38 ` Oleksij Rempel
2024-12-17 11:54 ` Vladimir Oltean
2024-12-17 12:22 ` Oleksij Rempel
2024-12-17 13:28 ` Vladimir Oltean
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=Z2FL-IcDLHXV-WCU@lore-desk \
--to=lorenzo@kernel.org \
--cc=Mark-MC.Lee@mediatek.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux@rempel-privat.de \
--cc=lorenzo.bianconi83@gmail.com \
--cc=lorenzo.bianconi@redhat.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=sean.wang@mediatek.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 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.