From: Vladimir Oltean <olteanv@gmail.com>
To: Xiaolei Wang <xiaolei.wang@windriver.com>, Andrew Lunn <andrew@lunn.ch>
Cc: linux@armlinux.org.uk, alexandre.torgue@foss.st.com,
joabreu@synopsys.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [net v2 PATCH] net: stmmac: Update CBS parameters when speed changes after linking up
Date: Thu, 30 May 2024 16:28:22 +0300 [thread overview]
Message-ID: <20240530132822.xv23at32wj73hzfj@skbuf> (raw)
In-Reply-To: <f8b0843f-7900-4ad0-9e70-c16175e893d9@lunn.ch>
On Thu, May 30, 2024 at 02:50:52PM +0200, Xiaolei Wang wrote:
> When the port is relinked, if the speed changes, the CBS parameters
> should be updated, so saving the user transmission parameters so
> that idle_slope and send_slope can be recalculated after the speed
> changes after linking up can help reconfigure CBS after the speed
> changes.
>
> Fixes: 1f705bc61aee ("net: stmmac: Add support for CBS QDISC")
> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
> ---
> v1 -> v2
> - Update CBS parameters when speed changes
May I ask what is the point of this patch? The bandwidth fraction, as
IEEE 802.1Q defines it, it a function of idleSlope / portTransmitRate,
the latter of which is a runtime variant. If the link speed changes at
runtime, which is entirely possible, I see no alternative than to let
user space figure out that this happened, and decide what to do. This is
a consequence of the fact that the tc-cbs UAPI takes the raw idleSlope
as direct input, rather than something more high level like the desired
bandwidth for the stream itself, which could be dynamically computed by
the kernel.
next prev parent reply other threads:[~2024-05-30 13:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 6:14 [net v2 PATCH] net: stmmac: Update CBS parameters when speed changes after linking up Xiaolei Wang
2024-05-30 12:50 ` Andrew Lunn
2024-05-30 13:28 ` Vladimir Oltean [this message]
2024-05-30 13:40 ` Russell King (Oracle)
2024-05-30 13:53 ` Vladimir Oltean
2024-05-30 14:14 ` Russell King (Oracle)
2024-05-30 14:35 ` Vladimir Oltean
2024-05-31 8:23 ` xiaolei wang
2024-05-30 16:13 ` Jakub Kicinski
2024-06-05 5:26 ` Dan Carpenter
2024-06-05 5:30 ` xiaolei wang
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=20240530132822.xv23at32wj73hzfj@skbuf \
--to=olteanv@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=xiaolei.wang@windriver.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