Re: [RFC 0/8] mbuf: structure reorganization

Hi Olivier,

-----Original Message-----
From: Olivier MATZ [mailto:olivier.matz@6wind.com]
Sent: Tuesday, February 21, 2017 9:54 AM
To: Ananyev, Konstantin <redacted>
Cc: Olivier Matz <redacted>; Jan Blunck <redacted>; dev@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"
[off-list ref] wrote:

quoted

Hi guys,

quoted

quoted

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