All of lore.kernel.org
 help / color / mirror / Atom feed
From: Esben Haabendal <esben@geanix.com>
To: "Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com>
Cc: Rohan G Thomas <rohan.g.thomas@intel.com>,
	 "David S . Miller" <davem@davemloft.net>,
	 Alexandre Torgue <alexandre.torgue@foss.st.com>,
	"Jose Abreu" <joabreu@synopsys.com>,
	 Eric Dumazet <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	 Rob Herring <robh+dt@kernel.org>,
	 "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	 "Serge Semin" <fancer.lancer@gmail.com>,
	 Andrew Halaney <ahalaney@redhat.com>, <elder@linaro.org>,
	 <netdev@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	 <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	 <quic_bhaviks@quicinc.com>, <kernel.upstream@quicinc.com>
Subject: Re: [PATCH net-next 2/2] net: stmmac: TBS support for platform driver
Date: Fri, 26 Jan 2024 09:43:28 +0100	[thread overview]
Message-ID: <87r0i44h8v.fsf@geanix.com> (raw)
In-Reply-To: <92892988-bb77-4075-812e-19f6112f436e@quicinc.com> (Abhishek Chauhan's message of "Wed, 10 Jan 2024 12:19:29 -0800")

"Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com> writes:

> Qualcomm had similar discussions with respect to enabling of TBS for a
> particular queue. We had similar discussion on these terms yesterday
> with Redhat. Adding Andrew from Redhat here
>
> What we discovered as part of the discussions is listed below.
>
> 1. Today upstream stmmac code is designed in such a way that TBS flag
> is put as part of queue configurations(see below snippet) and as well
> know that stmmac queue configuration comes from the dtsi file.
>
> //ndo_open => stmmac_open
> int tbs_en = priv->plat->tx_queues_cfg[chan].tbs_en;(comes from tx_queues_cfg)
>
> /* Setup per-TXQ tbs flag before TX descriptor alloc */
> tx_q->tbs |= tbs_en ? STMMAC_TBS_AVAIL : 0;
>
> 2. There is a no way to do this dynamically from user space because we don't have any 
> API exposed which can do it from user space

Not now. But why not extend ethtool API to allow enabling TBS for
supported controllers?

> and also TBS rely on special descriptors aka enhanced desc this cannot
> be done run time and stmmac has to be aware of it before we do
> DMA/MAC/MTL start.

Isn't this somewhat similar to changing the RX/TX ring parameters, which
I believe also is quite difficult to do at run time, and ethtool
therefore requires the interface to be down in oroer to change them?

> To do this dynamically would only mean stopping DMA/MAC/MTL realloc
> resources for enhanced desc and the starting MAC/DMA/MTL. This means
> we are disrupting other traffic(By stopping MAC block).

Yes. But you would be disrupting traffic less than by requiring a
complete reboot of the target which is needed if the devicetree must be
changed.

> 3. I dont think there is a way we can enable this dynamically today. I
> would like upstream community to share your thoughts as well.

Hereby done. Could we investigate the possibility of using ethtool to
change TBS enable/disable "run-time"?

> 4. I agree with Rohan's patch here and want upstream community to
> accept it. This will allow use to configure the queues where TBS needs
> to be enabled as hardcoding in the code unless upstream has better way
> to this using userspace.
>
> Please let us know if you think otherwise. 

/Esben

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Esben Haabendal <esben@geanix.com>
To: "Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com>
Cc: Rohan G Thomas <rohan.g.thomas@intel.com>,
	 "David S . Miller" <davem@davemloft.net>,
	 Alexandre Torgue <alexandre.torgue@foss.st.com>,
	"Jose Abreu" <joabreu@synopsys.com>,
	 Eric Dumazet <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	 Rob Herring <robh+dt@kernel.org>,
	 "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	 "Serge Semin" <fancer.lancer@gmail.com>,
	 Andrew Halaney <ahalaney@redhat.com>, <elder@linaro.org>,
	 <netdev@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	 <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	 <quic_bhaviks@quicinc.com>, <kernel.upstream@quicinc.com>
Subject: Re: [PATCH net-next 2/2] net: stmmac: TBS support for platform driver
Date: Fri, 26 Jan 2024 09:43:28 +0100	[thread overview]
Message-ID: <87r0i44h8v.fsf@geanix.com> (raw)
In-Reply-To: <92892988-bb77-4075-812e-19f6112f436e@quicinc.com> (Abhishek Chauhan's message of "Wed, 10 Jan 2024 12:19:29 -0800")

"Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com> writes:

> Qualcomm had similar discussions with respect to enabling of TBS for a
> particular queue. We had similar discussion on these terms yesterday
> with Redhat. Adding Andrew from Redhat here
>
> What we discovered as part of the discussions is listed below.
>
> 1. Today upstream stmmac code is designed in such a way that TBS flag
> is put as part of queue configurations(see below snippet) and as well
> know that stmmac queue configuration comes from the dtsi file.
>
> //ndo_open => stmmac_open
> int tbs_en = priv->plat->tx_queues_cfg[chan].tbs_en;(comes from tx_queues_cfg)
>
> /* Setup per-TXQ tbs flag before TX descriptor alloc */
> tx_q->tbs |= tbs_en ? STMMAC_TBS_AVAIL : 0;
>
> 2. There is a no way to do this dynamically from user space because we don't have any 
> API exposed which can do it from user space

Not now. But why not extend ethtool API to allow enabling TBS for
supported controllers?

> and also TBS rely on special descriptors aka enhanced desc this cannot
> be done run time and stmmac has to be aware of it before we do
> DMA/MAC/MTL start.

Isn't this somewhat similar to changing the RX/TX ring parameters, which
I believe also is quite difficult to do at run time, and ethtool
therefore requires the interface to be down in oroer to change them?

> To do this dynamically would only mean stopping DMA/MAC/MTL realloc
> resources for enhanced desc and the starting MAC/DMA/MTL. This means
> we are disrupting other traffic(By stopping MAC block).

Yes. But you would be disrupting traffic less than by requiring a
complete reboot of the target which is needed if the devicetree must be
changed.

> 3. I dont think there is a way we can enable this dynamically today. I
> would like upstream community to share your thoughts as well.

Hereby done. Could we investigate the possibility of using ethtool to
change TBS enable/disable "run-time"?

> 4. I agree with Rohan's patch here and want upstream community to
> accept it. This will allow use to configure the queues where TBS needs
> to be enabled as hardcoding in the code unless upstream has better way
> to this using userspace.
>
> Please let us know if you think otherwise. 

/Esben

  parent reply	other threads:[~2024-01-26  8:44 UTC|newest]

Thread overview: 36+ 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 ` 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-27 13:09   ` Rohan G Thomas
2023-09-28 18:09   ` Rob Herring
2023-09-28 18:09     ` Rob Herring
2023-09-29  5:17     ` rohan.g.thomas
2023-09-29  5:17       ` rohan.g.thomas
2024-01-26  8:52       ` Esben Haabendal
2024-01-26  8:52         ` Esben Haabendal
2024-01-26 17:36         ` rohan.g.thomas
2024-01-26 17:36           ` rohan.g.thomas
2024-01-26 20:19           ` Jakub Kicinski
2024-01-26 20:19             ` Jakub Kicinski
2024-01-26 23:22             ` Rohan G Thomas
2024-01-26 23:22               ` Rohan G Thomas
2023-09-27 13:09 ` [PATCH net-next 2/2] net: stmmac: TBS support for platform driver Rohan G Thomas
2023-09-27 13:09   ` Rohan G Thomas
2024-01-10 20:19   ` Abhishek Chauhan (ABC)
2024-01-10 20:19     ` Abhishek Chauhan (ABC)
2024-01-11 10:26     ` Rohan G Thomas
2024-01-11 10:26       ` Rohan G Thomas
2024-01-26  8:43     ` Esben Haabendal [this message]
2024-01-26  8:43       ` Esben Haabendal
2024-01-31 21:59       ` Abhishek Chauhan (ABC)
2024-01-31 21:59         ` Abhishek Chauhan (ABC)
2024-02-01  8:26         ` Esben Haabendal
2024-02-01  8:26           ` Esben Haabendal
2024-02-01 19:00           ` Abhishek Chauhan (ABC)
2024-02-01 19:00             ` Abhishek Chauhan (ABC)
2024-01-26  8:35   ` Esben Haabendal
2024-01-26  8:35     ` Esben Haabendal
2024-01-26 17:39     ` rohan.g.thomas
2024-01-26 17:39       ` rohan.g.thomas
2024-01-29 10:11       ` Esben Haabendal
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=87r0i44h8v.fsf@geanix.com \
    --to=esben@geanix.com \
    --cc=ahalaney@redhat.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=elder@linaro.org \
    --cc=fancer.lancer@gmail.com \
    --cc=joabreu@synopsys.com \
    --cc=kernel.upstream@quicinc.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=quic_abchauha@quicinc.com \
    --cc=quic_bhaviks@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=rohan.g.thomas@intel.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.