From: Vladimir Oltean <olteanv@gmail.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
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:30:40 +0200 [thread overview]
Message-ID: <20241217093040.x4yangwss2xa5lbz@skbuf> (raw)
In-Reply-To: <Z2FAUuOh4jrA0uGu@lore-desk>
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
(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'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?
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?
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?
next prev parent reply other threads:[~2024-12-17 9:30 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 [this message]
2024-12-17 10:01 ` Lorenzo Bianconi
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=20241217093040.x4yangwss2xa5lbz@skbuf \
--to=olteanv@gmail.com \
--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=lorenzo@kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox