>>
>> >> +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.
