From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: intel-wired-lan@lists.osuosl.org
Cc: vladimir.oltean@nxp.com, kurt@linutronix.de, anthony.l.nguyen@intel.com
Subject: [Intel-wired-lan] [PATCH iwl-net v3 0/4] igc: TX timestamping fixes
Date: Mon, 5 Jun 2023 18:33:21 -0700 [thread overview]
Message-ID: <20230606013325.602823-1-vinicius.gomes@intel.com> (raw)
Hi,
Changes from v2:
- Fixed possible race condition when disabling TX timestamping, added
a per queue flag, should make the hot path (no timestamps enabled)
a bit nicer (Jakub Kicinski);
- Renamed the igc_ptp_tx_work() to something more sensible (it's no
longer called in a workqueue) (Marc Kleine-Budde);
- Added some numbers, from the cover letter, to the commit message
itself (Paul Menzel);
Changes from v1:
- Squashed 3/5 into 1/5 (from v1), into 2/4 (v2) (Tony Nguyen);
- Improved the commit message of 1/4 (Kurt Kanzenbach);
- Added "Reviewed-by:" tags;
v1 link:
https://lore.kernel.org/intel-wired-lan/20230504235233.1850428-1-vinicius.gomes@intel.com/
Changes from the "for-next-queue" version:
- As this is intended for the iwl/net-queue tree, removed adding
support for adding the "extra" tstamp registers;
- Added "Fixes:" tags to the appropriate patches (Vladimir Oltean);
- Improved the check to catch the case that the skb has the
SKBTX_HW_TSTAMP flag, but TX timestamping is not enabled (Vladimir
Oltean);
- Ony check for timestamping timeouts if TX timestamping is enabled
(Vladimir Oltean);
for-next-queue version link:
https://lore.kernel.org/intel-wired-lan/20230228054534.1093483-1-vinicius.gomes@intel.com/
This is the fixes part of the series intended to add support for using
the 4 timestamp registers present in i225/i226.
Moving the timestamp handling to be inline with the interrupt handling
has the advantage of improving the TX timestamping retrieval latency,
here are some numbers using ntpperf:
Before:
$ sudo ./ntpperf -i enp3s0 -m 10:22:22:22:22:21 -d 192.168.1.3 -s 172.18.0.0/16 -I -H -o -37
| responses | TX timestamp offset (ns)
rate clients | lost invalid basic xleave | min mean max stddev
1000 100 0.00% 0.00% 0.00% 100.00% -56 +9 +52 19
1500 150 0.00% 0.00% 0.00% 100.00% -40 +30 +75 22
2250 225 0.00% 0.00% 0.00% 100.00% -11 +29 +72 15
3375 337 0.00% 0.00% 0.00% 100.00% -18 +40 +88 22
5062 506 0.00% 0.00% 0.00% 100.00% -19 +23 +77 15
7593 759 0.00% 0.00% 0.00% 100.00% +7 +47 +5168 43
11389 1138 0.00% 0.00% 0.00% 100.00% -11 +41 +5240 39
17083 1708 0.00% 0.00% 0.00% 100.00% +19 +60 +5288 50
25624 2562 0.00% 0.00% 0.00% 100.00% +1 +56 +5368 58
38436 3843 0.00% 0.00% 0.00% 100.00% -84 +12 +8847 66
57654 5765 0.00% 0.00% 100.00% 0.00%
86481 8648 0.00% 0.00% 100.00% 0.00%
129721 12972 0.00% 0.00% 100.00% 0.00%
194581 16384 0.00% 0.00% 100.00% 0.00%
291871 16384 27.35% 0.00% 72.65% 0.00%
437806 16384 50.05% 0.00% 49.95% 0.00%
After:
$ sudo ./ntpperf -i enp3s0 -m 10:22:22:22:22:21 -d 192.168.1.3 -s 172.18.0.0/16 -I -H -o -37
| responses | TX timestamp offset (ns)
rate clients | lost invalid basic xleave | min mean max stddev
1000 100 0.00% 0.00% 0.00% 100.00% -44 +0 +61 19
1500 150 0.00% 0.00% 0.00% 100.00% -6 +39 +81 16
2250 225 0.00% 0.00% 0.00% 100.00% -22 +25 +69 15
3375 337 0.00% 0.00% 0.00% 100.00% -28 +15 +56 14
5062 506 0.00% 0.00% 0.00% 100.00% +7 +78 +143 27
7593 759 0.00% 0.00% 0.00% 100.00% -54 +24 +144 47
11389 1138 0.00% 0.00% 0.00% 100.00% -90 -33 +28 21
17083 1708 0.00% 0.00% 0.00% 100.00% -50 -2 +35 14
25624 2562 0.00% 0.00% 0.00% 100.00% -62 +7 +66 23
38436 3843 0.00% 0.00% 0.00% 100.00% -33 +30 +5395 36
57654 5765 0.00% 0.00% 100.00% 0.00%
86481 8648 0.00% 0.00% 100.00% 0.00%
129721 12972 0.00% 0.00% 100.00% 0.00%
194581 16384 19.50% 0.00% 80.50% 0.00%
291871 16384 35.81% 0.00% 64.19% 0.00%
437806 16384 55.40% 0.00% 44.60% 0.00%
During this series, and to show that as is always the case, things are
never easy as they should be, a hardware issue was found, and it took
some time to find the workaround(s). The bug and workaround are better
explained in patch 5/5.
Note: the workaround has a simpler alternative, but it would involve
adding support for the other timestamp registers, and only using the
TXSTMP{H/L}_0 as a way to clear the interrupt. But I feel bad about
throwing this kind of resources away. Didn't test this extensively but
it should work.
Also, as Marc Kleine-Budde suggested, after some consensus is reached
on this series, most parts of it will be proposed for igb.
Vinicius Costa Gomes (4):
igc: Fix race condition in PTP tx code
igc: Check if hardware TX timestamping is enabled earlier
igc: Retrieve TX timestamp during interrupt handling
igc: Add workaround for missing timestamps
drivers/net/ethernet/intel/igc/igc.h | 8 +-
drivers/net/ethernet/intel/igc/igc_main.c | 14 ++-
drivers/net/ethernet/intel/igc/igc_ptp.c | 146 +++++++++++++++-------
3 files changed, 119 insertions(+), 49 deletions(-)
--
2.40.1
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next reply other threads:[~2023-06-06 1:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 1:33 Vinicius Costa Gomes [this message]
2023-06-06 1:33 ` [Intel-wired-lan] [PATCH iwl-net v3 1/4] igc: Fix race condition in PTP tx code Vinicius Costa Gomes
2023-06-06 1:33 ` [Intel-wired-lan] [PATCH iwl-net v3 2/4] igc: Check if hardware TX timestamping is enabled earlier Vinicius Costa Gomes
2023-06-06 1:33 ` [Intel-wired-lan] [PATCH iwl-net v3 3/4] igc: Retrieve TX timestamp during interrupt handling Vinicius Costa Gomes
2023-06-06 7:08 ` Miroslav Lichvar
2023-06-06 1:33 ` [Intel-wired-lan] [PATCH iwl-net v3 4/4] igc: Add workaround for missing timestamps Vinicius Costa Gomes
2023-06-06 5:07 ` Paul Menzel
2023-06-07 17:29 ` Vinicius Costa Gomes
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=20230606013325.602823-1-vinicius.gomes@intel.com \
--to=vinicius.gomes@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kurt@linutronix.de \
--cc=vladimir.oltean@nxp.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