Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

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