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? > > Konstantin
