From: Chuanyu Xue <chuanyu.xue@uconn.edu>
To: simei.su@intel.com
Cc: beilei.xing@intel.com, chuanyu.xue@uconn.edu, dev@dpdk.org,
qi.z.zhang@intel.com, wenzhuo.lu@intel.com
Subject: RE: [PATCH] net/e1000: support launchtime feature
Date: Thu, 21 Dec 2023 22:03:46 -0500 [thread overview]
Message-ID: <20231222030346.12805-1-chuanyu.xue@uconn.edu> (raw)
In-Reply-To: <SA1PR11MB661383A3DCD47CE2238117609C96A@SA1PR11MB6613.namprd11.prod.outlook.com>
Hi Simei,
Thank you so much for your review.
>>
>> /* QAV Tx mode control register */
>> #define E1000_I210_TQAVCTRL 0x3570
>> +#define E1000_I210_LAUNCH_OS0 0x3578
>
>What does this register mean?
>
"LAUNCH_OS0" is defined as LaunchOffset register, which sets the base time
for launchtime. Based on i210 datasheet V3.7 Sec 7.2.2.2.3, the actual launch
time is computed as 32 * (LaunchOffset + LaunchTime). In this context, the
register is used to set the LaunchOffset later as 0.
>>
>> + if (igb_tx_timestamp_dynflag > 0) {
>> + tqavctrl = E1000_READ_REG(hw, E1000_I210_TQAVCTRL);
>> + tqavctrl |= E1000_TQAVCTRL_MODE;
>> + tqavctrl |= E1000_TQAVCTRL_FETCH_ARB; /* Fetch the queue most
>> empty, no Round Robin*/
>> + tqavctrl |= E1000_TQAVCTRL_LAUNCH_TIMER_ENABLE; /* Enable
>> launch time */
>
> In kernel driver, "E1000_TQAVCTRL_DATATRANTIM (BIT(9))" and
> "E1000_TQAVCTRL_FETCHTIME_DELTA (0xFFFF << 16)" are set, does it have some
> other intention here?
"E1000_TQAVCTRL_DATATRANTIM" is same as "E1000_TQAVCTRL_LAUNCH_TIMER_ENABLE"
"E1000_TQAVCTRL_FETCHTIME_DELTA" maximizes the data fetch time.
If "E1000_TQAVCTRL_FETCH_ARB" is set, there is no need to set this field,
because the arbitrary fetching prioritizes the most empty queue, regardless
of the fetch time. (referring Sec 7.2.7.5)
I have also tested aligning with the kernel driver settings using (0xFFFF << 16)
and omitting 'E1000_TQAVCTRL_FETCH_ARB', the launchtime feature also worked
as expected. However, the arbitrary fetch mode seems more suitable
as DPDK lacks an interface to set fetch delay, unlike in the kernel which can
be configured (e.g., through 'Delta' in ETF Qdisc). Any suggestions here?
>> +static int
>> +eth_igb_read_clock(__rte_unused struct rte_eth_dev *dev, uint64_t
>> +*clock) {
>> + uint64_t systime_cycles;
>> + struct e1000_adapter *adapter = dev->data->dev_private;
>> +
>> + systime_cycles = igb_read_systime_cyclecounter(dev);
>> + uint64_t ns = rte_timecounter_update(&adapter->systime_tc,
>> systime_cycles);
>
>Do you also run "ptp timesync" when testing this launchtime feature?
>
I used `rte_eth_timesync_enable` function during the test. I am not familiar
with the `ptp timesync` in DPDK. If you are referring to something
else, could you please guide me on how to test it?
>>
>> +/* Macro to compensate latency in launch time offloading*/
>> +#define E1000_I210_LT_LATENCY 0x41F9
>
>What does this value depend on?
>
Through my test, I observed a constant latency between the launchtime
and the actual Tx time measured by the `rte_eth_timesync_read_tx_timestamp` function.
I didn't find a description of this latency in the datasheet.
In my test, the latency appears to be relative to the data rate, and
independent from the packet size and throughput. The latency slightly changed
in different experiments, but in each experiment, it remained constant for all the Tx packets.
I also tested this latency consistently on two different NICs (I210 GE-1T-X1, I210 X1-V2).
Here are some measurement results (in ns):
+-----------+---------------+---------------+---------------+---------------+---------------+
| Data Rate | Measurement 1 | Measurement 2 | Measurement 3 | Measurement 4 | Measurement 5 |
+-----------+---------------+---------------+---------------+---------------+---------------+
| 10M | 14400 | 14544 | 14384 | 14896 | 14336 |
+-----------+---------------+---------------+---------------+---------------+---------------+
| 100M | 31016 | 31016 | 31000 | 31000 | 31048 |
+-----------+---------------+---------------+---------------+---------------+---------------+
| 1G | 16880 | 16880 | 16880 | 16880 | 16880 |
+-----------+---------------+---------------+---------------+---------------+---------------+
Any suggestions here? Is it supposed to be embedded directly here or left to the
application level to compensate? I can fix it accordingly.
- Chuanyu
next prev parent reply other threads:[~2023-12-22 3:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-17 20:20 Chuanyu Xue
2023-12-20 6:29 ` Su, Simei
2023-12-22 3:03 ` Chuanyu Xue [this message]
2023-12-26 9:33 ` Su, Simei
2023-12-29 21:29 ` Chuanyu Xue
2024-01-03 2:26 ` Su, Simei
2024-01-03 21:52 ` Chuanyu Xue
2024-01-04 2:56 ` Su, Simei
2023-12-30 16:35 ` [PATCH v2] " Chuanyu Xue
2024-01-04 3:13 ` Su, Simei
2024-01-05 0:51 ` Zhang, Qi Z
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=20231222030346.12805-1-chuanyu.xue@uconn.edu \
--to=chuanyu.xue@uconn.edu \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
--cc=simei.su@intel.com \
--cc=wenzhuo.lu@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 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).