From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Paul Menzel <pmenzel@molgen.mpg.de>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
linux-kernel@vger.kernel.org,
Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 1/1] igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer
Date: Thu, 11 Jul 2024 11:22:26 -0700 [thread overview]
Message-ID: <87h6cvss9p.fsf@intel.com> (raw)
In-Reply-To: <20240706153807.3390950-1-faizal.abdul.rahim@linux.intel.com>
Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes:
> Testing uncovered that even when the taprio gate is closed, some packets
> still transmit.
>
> According to i225/6 hardware errata [1], traffic might overflow the
> planned QBV window. This happens because MAC maintains an internal buffer,
> primarily for supporting half duplex retries. Therefore, even when the
> gate closes, residual MAC data in the buffer may still transmit.
>
> To mitigate this for i226, reduce the MAC's internal buffer from 192 bytes
> to the recommended 88 bytes by modifying the RETX_CTL register value.
>
> This follows guidelines from:
> [1] Ethernet Controller I225/I22 Spec Update Rev 2.1 Errata Item 9:
> TSN: Packet Transmission Might Cross Qbv Window
> [2] I225/6 SW User Manual Rev 1.2.4: Section 8.11.5 Retry Buffer Control
>
> Note that the RETX_CTL register can't be used in TSN mode because half
> duplex feature cannot coexist with TSN.
>
> Test Steps:
> 1. Send taprio cmd to board A:
> tc qdisc replace dev enp1s0 parent root handle 100 taprio \
> num_tc 4 \
> map 3 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \
> queues 1@0 1@1 1@2 1@3 \
> base-time 0 \
> sched-entry S 0x07 500000 \
> sched-entry S 0x0f 500000 \
> flags 0x2 \
> txtime-delay 0
>
> Note that for TC3, gate should open for 500us and close for another
> 500us.
>
> 3. Take tcpdump log on Board B.
>
> 4. Send udp packets via UDP tai app from Board A to Board B.
>
> 5. Analyze tcpdump log via wireshark log on Board B. Ensure that the
> total time from the first to the last packet received during one cycle
> for TC3 does not exceed 500us.
>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> ---
> v1: https://patchwork.kernel.org/project/netdevbpf/patch/20240701100058.3301229-1-faizal.abdul.rahim@linux.intel.com/
>
> Changelog:
> v1 -> v2
> - Update commit description (Paul).
> - Rename qbvfullth -> qbvfullthreshold (Paul).
> ---
Looks fine.
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cheers,
--
Vinicius
WARNING: multiple messages have this Message-ID (diff)
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Paul Menzel <pmenzel@molgen.mpg.de>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Subject: Re: [PATCH iwl-net v2 1/1] igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer
Date: Thu, 11 Jul 2024 11:22:26 -0700 [thread overview]
Message-ID: <87h6cvss9p.fsf@intel.com> (raw)
In-Reply-To: <20240706153807.3390950-1-faizal.abdul.rahim@linux.intel.com>
Faizal Rahim <faizal.abdul.rahim@linux.intel.com> writes:
> Testing uncovered that even when the taprio gate is closed, some packets
> still transmit.
>
> According to i225/6 hardware errata [1], traffic might overflow the
> planned QBV window. This happens because MAC maintains an internal buffer,
> primarily for supporting half duplex retries. Therefore, even when the
> gate closes, residual MAC data in the buffer may still transmit.
>
> To mitigate this for i226, reduce the MAC's internal buffer from 192 bytes
> to the recommended 88 bytes by modifying the RETX_CTL register value.
>
> This follows guidelines from:
> [1] Ethernet Controller I225/I22 Spec Update Rev 2.1 Errata Item 9:
> TSN: Packet Transmission Might Cross Qbv Window
> [2] I225/6 SW User Manual Rev 1.2.4: Section 8.11.5 Retry Buffer Control
>
> Note that the RETX_CTL register can't be used in TSN mode because half
> duplex feature cannot coexist with TSN.
>
> Test Steps:
> 1. Send taprio cmd to board A:
> tc qdisc replace dev enp1s0 parent root handle 100 taprio \
> num_tc 4 \
> map 3 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \
> queues 1@0 1@1 1@2 1@3 \
> base-time 0 \
> sched-entry S 0x07 500000 \
> sched-entry S 0x0f 500000 \
> flags 0x2 \
> txtime-delay 0
>
> Note that for TC3, gate should open for 500us and close for another
> 500us.
>
> 3. Take tcpdump log on Board B.
>
> 4. Send udp packets via UDP tai app from Board A to Board B.
>
> 5. Analyze tcpdump log via wireshark log on Board B. Ensure that the
> total time from the first to the last packet received during one cycle
> for TC3 does not exceed 500us.
>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> ---
> v1: https://patchwork.kernel.org/project/netdevbpf/patch/20240701100058.3301229-1-faizal.abdul.rahim@linux.intel.com/
>
> Changelog:
> v1 -> v2
> - Update commit description (Paul).
> - Rename qbvfullth -> qbvfullthreshold (Paul).
> ---
Looks fine.
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cheers,
--
Vinicius
next prev parent reply other threads:[~2024-07-11 18:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-06 15:38 [Intel-wired-lan] [PATCH iwl-net v2 1/1] igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer Faizal Rahim
2024-07-06 15:38 ` Faizal Rahim
2024-07-11 18:22 ` Vinicius Costa Gomes [this message]
2024-07-11 18:22 ` Vinicius Costa Gomes
2024-08-01 7:26 ` [Intel-wired-lan] " Mor Bar-Gabay
2024-08-01 7:26 ` Mor Bar-Gabay
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=87h6cvss9p.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=faizal.abdul.rahim@linux.intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pmenzel@molgen.mpg.de \
/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.