Hi Jerin, On Fri, 24 Mar 2017 14:05:04 +0530, Jerin Jacob <jerin.ja...@caviumnetworks.com> wrote: > On Wed, Mar 22, 2017 at 05:42:12PM +0000, Ananyev, Konstantin wrote: > > > > Hi Olivier, > > > > > > > > > > Another thing that doesn't look very convenient to me here - > > > > > > > > We can have 2 different values of timestamp (both normalized > > > > > > > > and not) > > > > > > > > and there is no clear way for the application to know which one > > > > > > > > is in > > > > > > > > use right now. So each app writer would have to come-up with > > > > > > > > his own > > > > > > > > solution. > > > > > > > > > > > > > > It depends: > > > > > > > - the solution you describe is to have the application storing the > > > > > > > normalized value in its private metadata. > > > > > > > - another solution would be to store the normalized value in > > > > > > > m->timestamp. In this case, we would need a flag to tell if the > > > > > > > > > > > uint64_t dev_ops->timestamp_normalise(uint64_t timestamps); > > > > > > I think (but I'm not sure, it's really out of scope of this patchset), > > > that the timestamp synchronization API will be more complex than that. > > > > > > My current idea: > > > > > > - a rte_timestamp library holds the normalization code > > > - we decide, for instance, that "normalized" means: > > > - unit: nanosecond > > > - based on system clock > > > - reference: 0 = time when rte_timestamp_init() was called > > > - the PMD provides an API to get its clock > > > - the lib provides something like: > > > uint64_t rte_timestamp_normalize(unsigned int port_id, uint64_t > > > timestamp) > > > > > > > > > > 5. If the user wants to use that function it would be his > > > > responsibility to map mbuf > > > > to the port it was received from. > > > > > > Yes, if the application uses a port_id, it's its responsibility to ensure > > > that this port exists. > > > > Ok, so for 17.05 we'll have: > > - raw timestamp value inside mbuf > > - ol_flag bit to represenet is mbuf->timestamp value valid or not. > > That's it, correct? > > Hi Olivier, > > The ARM alignment fix also will be part of the v17.05. Right?
It's in this patchset, planned for v17.05. From what I see, there is no strong opposition to the patchset, so it should go in. (note, the v1 is here: http://dpdk.org/ml/archives/dev/2017-March/059693.html) If you (and others) have time to test or review, that may help to integrate it faster. Regards, Olivier