From: "Anwar, Md Danish" <a0501179@ti.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
MD Danish Anwar <danishanwar@ti.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
Andrew Lunn <andrew@lunn.ch>, Simon Horman <horms@kernel.org>,
Diogo Ivo <diogo.ivo@siemens.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Randy Dunlap <rdunlap@infradead.org>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Richard Cochran <richardcochran@gmail.com>,
Roger Quadros <rogerq@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
<linux-arm-kernel@lists.infradead.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <srk@ti.com>,
Jacob Keller <jacob.e.keller@intel.com>,
Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH net-next v9 2/2] net: ti: icssg_prueth: add TAPRIO offload support
Date: Fri, 7 Jun 2024 10:29:12 +0530 [thread overview]
Message-ID: <f81178c5-313e-47f6-bfe0-7e21a7f89a90@ti.com> (raw)
In-Reply-To: <20240603140559.krc6ap5qbltutsvj@skbuf>
On 6/3/2024 7:35 PM, Vladimir Oltean wrote:
> On Mon, Jun 03, 2024 at 04:51:00PM +0300, Vladimir Oltean wrote:
>>>>> +static void tas_reset(struct prueth_emac *emac)
>>>>> +{
>>>>> + struct tas_config *tas = &emac->qos.tas.config;
>>>>> + int i;
>>>>> +
>>>>> + for (i = 0; i < TAS_MAX_NUM_QUEUES; i++)
>>>>> + tas->max_sdu_table.max_sdu[i] = 2048;
>>>>
>>>> Macro + short comment for the magic number, please.
>>>>
>>>
>>> Sure I will add it. Each elements in this array is a 2 byte value
>>> showing the maximum length of frame to be allowed through each gate.
>>
>> Is the queueMaxSDU[] array active even with the TAS being in the reset
>> state? Does this configuration have any impact upon the device MTU?
>> I don't know why 2048 was chosen.
>
> Another comment here is: in the tc-taprio UAPI, a max-sdu value of 0
> is special and means "no maxSDU limit for this TX queue". You are
> programming the values from taprio straight away to hardware, so,
> assuming there's no bug there, it means that the hardware also
> understands 0 to mean "no maxSDU limit".
>
I discussed this with the firmware team. They are not treating 0 as
something special (""no maxSDU limit for this TX queue"). They have
limit on every queue. Driver needs to handle the max-sdu size carefully.
> If so, then during tas_reset(), after which the TAS should be disabled,
> why aren't you also using 0 as a default value, but 2048?
As using 0 doesn't mean anything special in firmware. The default value
during reset is kept as the max supported value.
There's also one thing missing here, the max-sdu table in firmware is
updated (by calling tas_update_maxsdu_table()) only once by driver
during tas_reset(). The firmware table should also be updated once
before triggering the list change so that the firmware would know what
are the max-sdu value that user has requested.
If a user request max-sdu as 0 0 0 80 for 4 queues. The driver will
update these values to firmware as PRUETH_MAX_MTU, PRUETH_MAX_MTU,
PRUETH_MAX_MTU, 80.
--
Thanks and Regards,
Md Danish Anwar
next prev parent reply other threads:[~2024-06-07 4:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 4:45 [PATCH net-next v9 0/2] Add TAPRIO offload support for ICSSG driver MD Danish Anwar
2024-05-31 4:45 ` [PATCH net-next v9 1/2] net: ti: icssg: Move icss_iep structure MD Danish Anwar
2024-05-31 4:45 ` [PATCH net-next v9 2/2] net: ti: icssg_prueth: add TAPRIO offload support MD Danish Anwar
2024-05-31 13:51 ` Vladimir Oltean
2024-06-03 12:12 ` MD Danish Anwar
2024-06-03 13:51 ` Vladimir Oltean
2024-06-03 14:05 ` Vladimir Oltean
2024-06-07 4:59 ` Anwar, Md Danish [this message]
2024-06-06 11:03 ` MD Danish Anwar
2024-06-06 14:17 ` Vladimir Oltean
2024-06-12 10:15 ` MD Danish Anwar
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=f81178c5-313e-47f6-bfe0-7e21a7f89a90@ti.com \
--to=a0501179@ti.com \
--cc=andrew@lunn.ch \
--cc=dan.carpenter@linaro.org \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=diogo.ivo@siemens.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=jan.kiszka@siemens.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=richardcochran@gmail.com \
--cc=rogerq@kernel.org \
--cc=rogerq@ti.com \
--cc=schnelle@linux.ibm.com \
--cc=srk@ti.com \
--cc=vigneshr@ti.com \
--cc=vladimir.oltean@nxp.com \
--cc=wsa+renesas@sang-engineering.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