DPDK patches and discussions
 help / color / mirror / Atom feed
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: Fri, 29 Dec 2023 16:29:34 -0500	[thread overview]
Message-ID: <20231229212934.98657-1-chuanyu.xue@uconn.edu> (raw)
In-Reply-To: <SA1PR11MB661385B0F2CD18A5454DF3AB9C98A@SA1PR11MB6613.namprd11.prod.outlook.com>

>> 
>> >> +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?
>
>Do you use your own application or DPDK application to test this launchtime feature,
>for example, dpdk testpmd?

Yes, I used my own application to test it. The benefit of launch time feature
in boundable delay and jitter is significant compared with when it is disabled. 

Specifically, my app periodically calls `rte_eth_tx_burst` with `rte_dynfield_timestamp` 
field on talker, and compares whether the receiving time in NIC hardware timestamp 
on listener is as expected. Talker and listener are directly connected by a RJ45 cable,
both installed with i210 NIC. The feature works perfect in my test.

I also tested it with testpmd with `txtimes` config. However it seems there is an issue 
in testpmd. Specifically the tx_only mode sends packets as fast as possible, results 
in an increasing gap between the current time and the scheduled transmission time.
Based on i210 NIC sheet Sec 7.2.2.2.3, the launch time should be within 
(current_time, current time + 0.5 Sec), thus most of tx packets are not scheduled. 
I got the similar test results with dpdk igc driver which already implemeted launch 
time feature.

Following is how I try to test with testpmd. Please let me know if I did something wrong.

	sudo ./dpdk-testpmd -- -i --forward-mode=txonly
	
	testpmd> port stop 0
	testpmd> set burst 1
	testpmd> set txtimes 100000000,0
	testpmd> port config 0 tx_offload send_on_timestamp on
	testpmd> port start 0
	testpmd> start

>
>> +-----------+---------------+---------------+---------------+---------------+---------------+
>> | 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.
>
>I think it can be put here directly just as you do.

Got it. Will keep this delay compensiation here and revise it in the next batch version.

  reply	other threads:[~2023-12-29 21:29 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
2023-12-26  9:33     ` Su, Simei
2023-12-29 21:29       ` Chuanyu Xue [this message]
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=20231229212934.98657-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).