From: "Su, Simei" <simei.su@intel.com>
To: Chuanyu Xue <chuanyu.xue@uconn.edu>
Cc: "Xing, Beilei" <beilei.xing@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Subject: RE: [PATCH] net/e1000: support launchtime feature
Date: Wed, 3 Jan 2024 02:26:17 +0000 [thread overview]
Message-ID: <SA1PR11MB66132175D7AC5F1512539E5F9C60A@SA1PR11MB6613.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20231229212934.98657-1-chuanyu.xue@uconn.edu>
Hi Chuanyu,
> -----Original Message-----
> From: Chuanyu Xue <chuanyu.xue@uconn.edu>
> Sent: Saturday, December 30, 2023 5:30 AM
> To: Su, Simei <simei.su@intel.com>
> Cc: Xing, Beilei <beilei.xing@intel.com>; chuanyu.xue@uconn.edu;
> dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>
> Subject: RE: [PATCH] net/e1000: support launchtime feature
>
> >>
> >> >> +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.
OK, it sounds good.
>
> 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
When testing launch time feature with igc driver, firstly, some code change made in txonly.c:
pkt->ol_flags |= RTE_MBUF_F_TX_IEEE1588_TMST; (this flag should be added to forward PTP packet with hardware Tx timestamp)
# ./build/app/dpdk-testpmd -a 0000:81:00.0 -c f -n 4 -- -i --tx-offloads=0x200000
testpmd> set burst 1
testpmd> set fwd txonly
testpmd> set txtimes 1000000,0
testpmd> start
On receiver side (with tcpdump):
# tcpdump -Q in -ttt -ni ens25f3 --time-stamp-precision=nano -j adapter_unsynced -c 32
Thanks,
Simei
>
> >
> >> +-----------+---------------+---------------+---------------+---------------+---------------+
> >> | 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.
next prev parent reply other threads:[~2024-01-03 2:26 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
2024-01-03 2:26 ` Su, Simei [this message]
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=SA1PR11MB66132175D7AC5F1512539E5F9C60A@SA1PR11MB6613.namprd11.prod.outlook.com \
--to=simei.su@intel.com \
--cc=beilei.xing@intel.com \
--cc=chuanyu.xue@uconn.edu \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@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).