From: Rohan G Thomas <rohan.g.thomas@intel.com>
To: kuba@kernel.org
Cc: alexandre.torgue@foss.st.com, conor+dt@kernel.org,
davem@davemloft.net, devicetree@vger.kernel.org,
edumazet@google.com, esben@geanix.com, fancer.lancer@gmail.com,
joabreu@synopsys.com, krzysztof.kozlowski+dt@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
pabeni@redhat.com, peppe.cavallaro@st.com, robh@kernel.org,
rohan.g.thomas@intel.com
Subject: RE: [PATCH net-next 1/2] dt-bindings: net: snps,dwmac: Time Based Scheduling
Date: Sat, 27 Jan 2024 07:22:30 +0800 [thread overview]
Message-ID: <20240126232230.15733-1-rohan.g.thomas@intel.com> (raw)
In-Reply-To: <20240126121928.48a44327@kernel.org>
On Fri, 26 Jan 2024 12:19:28 -0800, Jakub Kicinski wrote:
> > > The tricky part here is that the whole devicetree bindings story for the
> > > stmmac driver is filled with such configuration choices. As such, it is
> > > only natural to add the property you are suggesting here. I completely
> > > agree. But you can also argue that it is "wrong", because it does not
> > > just describe the hardware, but also a configuration choice.
> >
> > Isn't this requirement of using enhanced tx desc instead of normal tx
> > desc to support TBS is specific to Synopsys IP? Switching from
> > normal desc to enhanced desc at the time of tc-etf qdisc offload
> > cannot be done without traffic disruption, which I don't think is
> > acceptable. Since this behavior is IP specific, can we consider
> > this as an OS configuration choice?
>
> Why is traffic disruption not acceptable when TBS gets turned on?
> User has to install the right qdisc to enable TBS, I presume,
> installing qdiscs destroys the old ones which also leads to packet
> drops.
Hi Jakub,
Agreed that packet loss is acceptable during qdisc install.
Sorry, I'm a little out of context in the above statements.
Switching between normal and enhanced desc is really not needed as
enhanced desc can support transmission of packets that don't have any
launch time also. So for any tbs supported queues we can enable
enhanced desc for tbs during stmmac_open itself.
As I mentioned in my previous reply:
> > Agreed that this feature(use of enhanced desc) can be enabled from
> > glue drivers. But I added this dt property, thinking this feature is
> > specific and common to DWMAC core and we can enable this feature for
> > stmmac platform driver without a glue driver. If this is not
> > acceptable, I can think of doing this from the glue driver.
Like Esben mentioned I think enabling tbs_en flag explicitly from the
glue driver is the way to enable tbs support for a tx-queue right now.
BR,
Rohan
next prev parent reply other threads:[~2024-01-26 23:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 13:09 [PATCH net-next 0/2] net: stmmac: TBS support for platform driver Rohan G Thomas
2023-09-27 13:09 ` [PATCH net-next 1/2] dt-bindings: net: snps,dwmac: Time Based Scheduling Rohan G Thomas
2023-09-28 18:09 ` Rob Herring
2023-09-29 5:17 ` rohan.g.thomas
2024-01-26 8:52 ` Esben Haabendal
2024-01-26 17:36 ` rohan.g.thomas
2024-01-26 20:19 ` Jakub Kicinski
2024-01-26 23:22 ` Rohan G Thomas [this message]
2023-09-27 13:09 ` [PATCH net-next 2/2] net: stmmac: TBS support for platform driver Rohan G Thomas
2024-01-10 20:19 ` Abhishek Chauhan (ABC)
2024-01-11 10:26 ` Rohan G Thomas
2024-01-26 8:43 ` Esben Haabendal
2024-01-31 21:59 ` Abhishek Chauhan (ABC)
2024-02-01 8:26 ` Esben Haabendal
2024-02-01 19:00 ` Abhishek Chauhan (ABC)
2024-01-26 8:35 ` Esben Haabendal
2024-01-26 17:39 ` rohan.g.thomas
2024-01-29 10:11 ` Esben Haabendal
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=20240126232230.15733-1-rohan.g.thomas@intel.com \
--to=rohan.g.thomas@intel.com \
--cc=alexandre.torgue@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=esben@geanix.com \
--cc=fancer.lancer@gmail.com \
--cc=joabreu@synopsys.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=robh@kernel.org \
/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).