Hello Konstantin,
>
> My vote also would be to have timestamp in the second cache line.
> About moving seqn to the 2-nd cache line too - that's probably a fair point.
It may impact throughput till ~6% for applications required such embedded
Timestamps.
> About the rest of the patch:
> Do you
Hello Reshma
> I just read this mail chain, to make every one aware again, I am emphasizing
> on the point that I am also adding new "time_arraived" field to mbuf struct as
> part of below 17.02 Road map item.
Thanks for your work for extending statistics support in DPDK.
"time_arrived" points
Hello Oliver
Great thanks for your review and con
> > - include uint64_t timestamp field into rte_mbuf with minimal impact to
> > throughput/latency. Keep it just simple uint64_t in ns (more than 580
> > years) would be enough for immediate needs while using full
> > struct timespec with
immediately after completion.
Enabling/disabling time synchronization DPDK API was added.
Signed-off-by: Oleg Kuporosov
---
drivers/net/mlx5/mlx5.c | 7 +-
drivers/net/mlx5/mlx5.h | 10 +-
drivers/net/mlx5/mlx5_defs.h | 4 +
drivers/net/mlx5
there as
it is under macro compilation but can be extended in the future.
This feature is required for debugging/testing purposes for real time HW
packet timestamping.
Signed-off-by: Oleg Kuporosov
---
app/test-pmd/cmdline.c | 122
app/test-pmd
.
- such move will only impact for pretty rare usable VLAN RX stripping
mode for outer TCI (it used only for one NIC i40e from the whole set and
allows to keep minimal performance impact for RX/TX timestamps.
Signed-off-by: Oleg Kuporosov
---
lib/librte_mbuf/rte_mbuf.h | 6 --
1 file
.
- PMD can fill the field in their callback completion routines
depending on enabling this feature in runtime.
We evaluated other possible options but looks it will have even worse
performance impact.
Oleg Kuporosov (3):
mbuf: embedding timestamp into the packet
app/testpmd: enabled
7 matches
Mail list logo
