[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