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

[Olivier Matz]

Hi Jerin,

On Fri, 24 Mar 2017 14:05:04 +0530, Jerin Jacob <jerin.jacob at 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