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

Jan Blunck jblunck at infradead.org
Tue Feb 21 17:12:12 CET 2017


On Tue, Feb 21, 2017 at 10:54 AM, Olivier MATZ <olivier.matz at 6wind.com> wrote:
> Hi Jan,
>
> On Mon, 20 Feb 2017 10:27:40 +0100, Jan Blunck <jblunck at infradead.org>
> wrote:
>> On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz
>> <olivier.matz at 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, ...
>

One doesn't drop, forward, reorder or decrypt packets based on the
timestamp value.

Common use cases for timestamps are analytics applications or circuit
breakers where you want to ensure that your algos don't act upon stale
data. This is more application layer / slow path work.

> 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.
>

I believe there is a difference between dataplane relevant
functionally and non-functional features. If you structurally
normalize the later you will end up making everyone pay for a feature
that is only relevant to a particular group of users. In that case I
would at least expect that the support for timestamps can get selected
at compile time.

>>
>> 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.
>

Access through PMD specific function pointers should be relatively
fast on access. Modern architecture optimize that use case well
enough.

> 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?

What is you plan for devices that already put the timestamp relative
to the packet data? Do you still want to duplicate and normalize it
into the rte_mbuf field?

What is recommended to do for PMDs that don't support HW timestamps?
Do they still fill this field?


More information about the dev mailing list