> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Tuesday, 13 December 2022 16.50
>
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that
> were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rja...@redhat.com>
> > Acked-by: Morten Brørup <m...@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
>
> As you may have noticed, I forgot to add -v4 for that iteration...
>
> > diff --git a/lib/eal/include/rte_lcore.h
> b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int
> lcore_id, void *arg);
> > int
> > rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + * The lcore to consider.
> > + * @param [out] busy_cycles
> > + * The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + * The total amount of time since application start, in TSC
> cycles.
> > + * @return
> > + * - 0 if both busy and total were set correctly.
> > + * - a negative value if the information is not available or if
> any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t
> *total_cycles);
>
> Instead of two uint64_t pointers, I was thinking a better approach
> would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
>
> Thoughts?
I like the idea.
For compatibility between newer DPDK libraries (with more fields) and older
applications, the callback should return an indication of how much of the
structure it has filled, so DPDK knows that some fields are unfilled.
The simplest method would be that the callback returns the number of bytes of
the structure filled instead of 0 on success. However, that would not allow for
holes in the returned structure.
Alternatively, a bitfield can be the first field in the structure, each bit
representing a data field in the structure. That would allow flexibility to
fill any of up to 64 fields. So with total_cycles and busy_cycles as data
fields, the returned structure would contain e.g. {3, 1000, 900}. (As a
personal preference, I would put total_cycles before busy_cycles in such a
structure.)
And I'm not saying that fields must be uint64_t; they can be any size.
On the other hand, I might be suggesting too much flexibility with the bitfield
proposal. Perhaps the simple method suffices. And perhaps only uint64_t fields
suffice.
-Morten
