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

Olivier MATZ olivier.matz at 6wind.com
Tue Feb 21 10:53:49 CET 2017


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

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


Thanks,
Olivier


More information about the dev mailing list