From: "Morten Brørup" <mb@smartsharesystems.com>
To: "fengchengwen" <fengchengwen@huawei.com>,
"Kevin Laatz" <kevin.laatz@intel.com>,
"Bruce Richardson" <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>, <thomas@monjalon.net>
Subject: RE: [PATCH] dmadev: add tracepoints
Date: Thu, 13 Apr 2023 10:25:57 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8786D@smartserver.smartshare.dk> (raw)
In-Reply-To: <a10e0b03-815e-9085-5f2d-e3a1bf7758ba@huawei.com>
> From: fengchengwen [mailto:fengchengwen@huawei.com]
> Sent: Thursday, 13 April 2023 08.30
>
> On 2023/4/12 19:00, Morten Brørup wrote:
> >> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> >> Sent: Wednesday, 12 April 2023 04.48
> >>
> >> Add tracepoints at important APIs for tracing support.
> >>
> >> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >> ---
> >
>
> ...
>
> >> +)
> >> +
> >> +RTE_TRACE_POINT(
> >> + rte_dma_trace_stats_get,
> >
> > This should be a fast path trace point.
> > For reference, ethdev considers rte_eth_stats_get() a fast path function.
>
> Emm, I think it should discuss more, and make it clear.
>
> The cryptodev and dmadev trace-points both make 'rte_xxx_trace_stats_get' as a
> slow path function.
Then those stats tracepoints should be fixed, so they behave like ethdev.
> And it mainly refer to the fast path API (means if a API is fast path then
> make it as a fast-path trace-points).
Dataplane functions must obviously be RTE_TRACE_POINT_FP. But some non-dataplane functions must also be RTE_TRACE_POINT_FP.
>
> But the ethdev trace-points treats 'calls in loop function(such as
> rte_eth_trace_stats_get/rte_eth_trace_link_get/...)'
> as fast path trace-points.
Yes. Such "grey area" functions must use FP trace. Please refer to the Techboard decision to treat them as FP trace [1].
[1]: http://inbox.dpdk.org/dev/2325762.trqCLbgVIZ@thomas/
The techboard made this decision when trace was introduced to ethdev, and it seems that it was not caught in review when trace was added to cryptodev.
PS: The trace point macro names are unfortunate... Since RTE_TRACE_POINT_FP is not only for Fast Path functions, they should have been named RTE_TRACE_POINT and RTE_TRACE_POINT_SLOW instead of RTE_TRACE_POINT_FP and RTE_TRACE_POINT. But it is too late to change now.
>
> >
> >> + RTE_TRACE_POINT_ARGS(int16_t dev_id, uint16_t vchan,
> >> + struct rte_dma_stats *stats, int ret),
> >> + rte_trace_point_emit_i16(dev_id);
> >> + rte_trace_point_emit_u16(vchan);
> >> + rte_trace_point_emit_u64(stats->submitted);
> >> + rte_trace_point_emit_u64(stats->completed);
> >> + rte_trace_point_emit_u64(stats->errors);
> >> + rte_trace_point_emit_int(ret);
> >> +)
> >> +
>
> ...
>
> >> diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
> >> index 7031d6b335..4ee1b3f74a 100644
> >> --- a/lib/dmadev/version.map
> >> +++ b/lib/dmadev/version.map
> >> @@ -1,6 +1,16 @@
> >> EXPERIMENTAL {
> >> global:
> >>
> >> + # added in 23.07
> >> + __rte_dma_trace_burst_capacity;
> >> + __rte_dma_trace_completed;
> >> + __rte_dma_trace_completed_status;
> >> + __rte_dma_trace_copy;
> >> + __rte_dma_trace_copy_sg;
> >> + __rte_dma_trace_fill;
> >> + __rte_dma_trace_submit;
> >> +
> >
> > Intuitively, I would suppose that the 23.07 functions should be listed after
> the 21.11 functions, not before.
>
> +1, will fix in v2
>
> >
> >> + # added in 21.11
> >
> > Good catch.
> >
> >> rte_dma_close;
> >> rte_dma_configure;
> >> rte_dma_count_avail;
> >> --
> >> 2.17.1
> >
> >
> > .
> >
next prev parent reply other threads:[~2023-04-13 8:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 2:48 Chengwen Feng
2023-04-12 9:52 ` Bruce Richardson
2023-04-13 3:44 ` fengchengwen
2023-04-13 8:45 ` Bruce Richardson
2023-04-12 11:00 ` Morten Brørup
2023-04-13 6:30 ` fengchengwen
2023-04-13 8:25 ` Morten Brørup [this message]
2023-04-15 0:33 ` [PATCH v3] " Chengwen Feng
2023-05-24 21:12 ` Thomas Monjalon
2023-05-27 0:17 ` fengchengwen
2023-05-26 8:42 ` [PATCH v4] " Chengwen Feng
2023-07-03 3:54 ` fengchengwen
2023-07-07 10:40 ` Thomas Monjalon
2023-07-09 3:23 ` fengchengwen
2023-07-10 6:49 ` Thomas Monjalon
2023-07-10 7:50 ` fengchengwen
2023-07-31 12:48 ` Thomas Monjalon
2023-08-03 7:52 ` fengchengwen
2023-08-14 14:16 ` Thomas Monjalon
2023-10-11 9:55 ` fengchengwen
2023-11-06 20:59 ` Thomas Monjalon
2023-11-07 1:26 ` fengchengwen
2024-01-12 10:38 ` fengchengwen
2023-10-20 2:21 ` [PATCH] dmadev: add tracepoints at control path APIs Chengwen Feng
2023-11-06 20:55 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35D8786D@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=kevin.laatz@intel.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).