28/04/2017 02:19, Wu, Jingjing: > > 25/04/2017 16:02, Wu, Jingjing: > > > From: Oleg Kuporosov > > > > Implemented two methods of control > > > > > > > > - by --enable-timestamps CL testpmd application we can enable > > timestamping > > > > for all ports; > > > > - in interactive mode port config <port> timestamps on|off is able to > > > > configure timestamping per specific port. > > > > > > > > The control doesn't interact with IEEE1588 PTP implementation 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. > > > > > > We have ieee1588fwd.c to demo the timesync enable/disable, can we > > > reuse The fwd engine instead of defining new commands? > > > > Yes for IEEE1588 feature, we should use app/test-pmd/ieee1588fwd.c. > > > > There is more to say about this feature. > > > > The main goal of this patchset was to add a timestamp in the mbuf. > > It has been done by another patchset in 17.05. > > OK. But it is not clear now what is the timestamp for, right?
Olivier can comment on the Rx timestamp (PKT_RX_TIMESTAMP). Please Jingjing (or Pablo or Daniel), could you explain the relation with PKT_TX_IEEE1588_TMST? > > Do we know how to test this timestamp in testpmd? > > Mbuf dump can show this value. The problem is if we can use the > rte_eth_timesync_enable/disable to indicate the timestamp > is in mbuf or not. Please could you describe the problem? > > About IEEE1588 feature, why is there a config option? > > CONFIG_RTE_LIBRTE_IEEE1588 > > A feature should never be disabled at compile time. > > There is also a runtime enablement with rte_eth_timesync_enable(). > > > > I think we need some discussions here. > > Yes, I agree. What is your opinion? What prevents from removing CONFIG_RTE_LIBRTE_IEEE1588?
