Hi Jan,
On Mon, 20 Feb 2017 10:27:40 +0100, Jan Blunck <jblu...@infradead.org>
wrote:
> On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz
> <olivier.m...@6wind.com> wrote:
> >
> > 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.
> >
>
> Timestamps are non-functional data. I believe they don't deserve to be
> data normalized.
I don't really see why timestamp is non-functional, compared to rss
hash, flow director id, packet type, seqn, ...
I think the goal of DPDK is to provide a generic/normalized API for
such features (like for offload), so it can be used by an application
whatever the underlying driver.
>
> It would be beneficial to normalize the access of non-functional data.
> That would require some kind of extension or feature flags, e.g. like
> some uverb structures support extensions. This would allow the NICs
> that support timestamps to do the minimal amount of work during burst
> and defer data normalization to the time of access. That would also
> safe everyone from wasting 64bit in the first cacheline in case
> timestamps are not supported or unused.
I agree that we could start to think about "extensible" mbufs. In few
words, I think we could have:
- only general fields are static
- the application registers room in mbuf structure for all features it
will use
It would rationalize the room used in mbuf, at the cost of a more
complex/slow access to the data in PMDs and application, since the
offset won't be static.
But to me, this is another work, and a much harder one since it will
impact a lot of PMD code (some are using vector instructions and are
quite hard to change). Moreover, we first have to prove that it would
perform better than we we have now, especially knowing that size of the
cache line will probably change to 128B for many architectures.
Now back on the patch, yes, it's true we are consuming 64bits in the
first cache line. But what are the other options? Having it in the
second cache line would allow free this space for future use. But don't
you think we could optimize current use, and rework the structure if
new needs -- that are more important than timestamp for the majority--
appear?
Thanks,
Olivier
