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

Ananyev, Konstantin konstantin.ananyev at intel.com
Tue Feb 21 11:28:00 CET 2017


Hi Olivier,

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, February 21, 2017 9:54 AM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Cc: Olivier Matz <olivier.matz at 6wind.com>; Jan Blunck <jblunck at infradead.org>; dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization
> 
> Hi Konstantin,
> 
> On Fri, 17 Feb 2017 18:42:01 +0000, "Ananyev, Konstantin"
> <konstantin.ananyev at intel.com> wrote:
> > Hi guys,
> >
> > > > My point is that I still doubt that it belongs into the first
> > > > cacheline. It requires accessing other structures for converting
> > > > into nanoseconds anyway. Optimally I would like to see this
> > > > happening on access instead but if that isn't achievable at least
> > > > in a second step.
> > >
> > > Sorry, I don't really get your point. My comprehension of the
> > > timestamp usage in a PMD is as following:
> > >
> > > rx_burst(struct rxq *rxq, ...)
> > > {
> > > 	unsigned long factor = rxq->timestamp_factor;
> > > 	unsigned port = rxq->port;
> > >
> > > 	for each hw_desc {
> > > 		m = rte_pktmbuf_alloc(rxq->pool);
> > > 		m->len = hw_desc->len;
> > > 		m->port = port;
> > > 		m->ol_flags =
> > > 		...
> > > 		m->timestamp = hw_desc->timestamp * factor;
> > > 	}
> > > 	...
> > > }
> > >
> > > In that case, I think it deserves to be in the 1st cache line.
> >
> > So you are saying that:
> > - for some HW that DPDK supports (mlx?) timestamp information
> > Is available in HW RX descriptor
> > - and as soon timestamp field will be available in mbuf, you plan
> > to populate it using this HW RXD field.
> > Is that so?
> 
> Yes, that's what I'm seeing in mellanox's patchset:
> http://dpdk.org/ml/archives/dev/2016-October/048810.html

Have to admit that I saw that patch before, but missed the fact that
timestamp value is taken from HW RXD.
Ok, then I suppose I don't' have any good reason to object against
putting it in the first cache-line.

> 
> Do you know if Intel has plans to support some sort of timestamp using
> this timestamp field?
> 

As I remember, metrics library uses it, but right now it is filled by SW.
Konstantin



More information about the dev mailing list