On Thu, Oct 13, 2016 at 02:35:05PM +0000, Oleg Kuporosov wrote: > > Hello DPDK Developers, > > Financial Services Industry which is pretty eager for several DPDK > features especially low latency while high throughput. The major issue > so far for increasing DPDK adoption there is requirement for several > applications (capturers, some trading algorithms) to support of accurate > timestamping. The requirement mostly came from regulatory and customers > need strictly follow it. > > Current state of timestamping support in DPDK looks pretty good: > - there is API to enable/disable timestamping acquisition by > rte_eth_timesync_enable/disable > - get timestamps itself by timesync_read_rx/tx_timestamp > - and even implementation of NTP IEEE 1588 for time synchronization > by rte_eth_timesync_adjust_read/write_time APIs. > > But it misses the most important feature there ? embedding timestamp > in rte_mbuf aligning it with packet. > > We would like to change this to increase DPDK adoption for several new > DPDK-based applications for FSI segment. It also might be very > applicable for several RT media and debugging purposes of network > flows/streams in other segments like HPC. > > There are several thoughts how to improve there: > - 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 twice bigger size would have much stronger > performance impact as missed cacheline0. It is possible as there is > 6-bytes gap in 1st cacheline (fast path) and moving uint16_t > vlan_tci_outer field to 2nd cacheline. > - 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 keep minimal performance impact for timestamps. > - 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 control for packet timestamps > net/mlx5: implementation of Rx packet timestamping support > > app/test-pmd/cmdline.c | 122 +++++++++++++++ > app/test-pmd/parameters.c | 4 + > app/test-pmd/testpmd.c | 5 + > app/test-pmd/testpmd.h | 1 + > doc/guides/testpmd_app_ug/run_app.rst | 4 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 + > drivers/net/mlx5/mlx5.c | 7 +- > drivers/net/mlx5/mlx5.h | 10 +- > drivers/net/mlx5/mlx5_defs.h | 4 + > drivers/net/mlx5/mlx5_ethdev.c | 222 > +++++++++++++++++++++++++++- > drivers/net/mlx5/mlx5_rxq.c | 2 + > drivers/net/mlx5/mlx5_rxtx.c | 19 ++- > drivers/net/mlx5/mlx5_rxtx.h | 7 +- > drivers/net/mlx5/mlx5_time.h | 53 +++++++ > drivers/net/mlx5/mlx5_trigger.c | 1 + > lib/librte_eal/common/include/rte_time.h | 45 ++++++ > lib/librte_mbuf/rte_mbuf.h | 6 +- > 17 files changed, 507 insertions(+), 12 deletions(-) > create mode 100644 drivers/net/mlx5/mlx5_time.h > > Thanks, > Oleg. > -- > 1.8.3.1
Reviewed-by: Nelio Laranjeiro <nelio.laranjeiro at 6wind.com> -- N?lio Laranjeiro 6WIND