From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Ankur Dwivedi <adwivedi@marvell.com>,
dev@dpdk.org, David Marchand <david.marchand@redhat.com>
Cc: thomas@monjalon.net, david.marchand@redhat.com, mdr@ashroe.eu,
orika@nvidia.com, chas3@att.com, humin29@huawei.com,
linville@tuxdriver.com, ciara.loftus@intel.com,
qi.z.zhang@intel.com, mw@semihalf.com, mk@semihalf.com,
shaibran@amazon.com, evgenys@amazon.com, igorch@amazon.com,
chandu@amd.com, irusskikh@marvell.com,
shepard.siegel@atomicrules.com, ed.czeck@atomicrules.com,
john.miller@atomicrules.com, ajit.khaparde@broadcom.com,
somnath.kotur@broadcom.com, jerinj@marvell.com,
mczekaj@marvell.com, sthotton@marvell.com,
srinivasan@marvell.com, hkalra@marvell.com,
rahul.lakkireddy@chelsio.com, johndale@cisco.com,
hyonkim@cisco.com, liudongdong3@huawei.com,
yisen.zhuang@huawei.com, xuanziyang2@huawei.com,
cloud.wangxiaoyun@huawei.com, zhouguoyang@huawei.com,
simei.su@intel.com, wenjun1.wu@intel.com, qiming.yang@intel.com,
Yuying.Zhang@intel.com, beilei.xing@intel.com,
xiao.w.wang@intel.com, jingjing.wu@intel.com,
junfeng.guo@intel.com, rosen.xu@intel.com,
ndabilpuram@marvell.com, kirankumark@marvell.com,
skori@marvell.com, skoteshwar@marvell.com, lironh@marvell.com,
zr@semihalf.com, radhac@marvell.com, vburru@marvell.com,
sedara@marvell.com, matan@nvidia.com, viacheslavo@nvidia.com,
longli@microsoft.com, spinler@cesnet.cz,
chaoyong.he@corigine.com, niklas.soderlund@corigine.com,
hemant.agrawal@nxp.com, sachin.saxena@oss.nxp.com,
g.singh@nxp.com, apeksha.gupta@nxp.com, sachin.saxena@nxp.com,
aboyer@pensando.io, rmody@marvell.com, shshaikh@marvell.com,
dsinghrawat@marvell.com, andrew.rybchenko@oktetlabs.ru,
jiawenwu@trustnetic.com, jianwang@trustnetic.com,
jbehrens@vmware.com, maxime.coquelin@redhat.com,
chenbo.xia@intel.com, steven.webster@windriver.com,
matt.peters@windriver.com, bruce.richardson@intel.com,
mtetsuyah@gmail.com, grive@u256.net, jasvinder.singh@intel.com,
cristian.dumitrescu@intel.com, jgrajcia@cisco.com,
mb@smartsharesystems.com
Subject: Re: [PATCH v6 2/6] ethdev: add trace points for ethdev (part one)
Date: Mon, 23 Jan 2023 17:28:46 +0000 [thread overview]
Message-ID: <614e22c6-8485-0e8d-742e-b3d100f96468@amd.com> (raw)
In-Reply-To: <20230120084059.2926575-3-adwivedi@marvell.com>
On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
> Adds trace points for ethdev functions.
> Moved the rte_ethdev_trace_rx_burst and rte_ethdev_trace_tx_burst to
> a new file rte_ethdev_trace_fp_burst.h. This is needed to resolve
> cyclic dependency between rte_ethdev.h and rte_ethdev_trace_fp.h.
>
> Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
<...>
> +RTE_TRACE_POINT_REGISTER(rte_eth_trace_rx_hairpin_queue_setup,
> + lib.ethdev.rx.hairpin_queue_setup)
> +
s/rx.hairpin_queue_setup/rx_hairpin_queue_setup/ ?
> +RTE_TRACE_POINT_REGISTER(rte_eth_trace_tx_hairpin_queue_setup,
> + lib.ethdev.tx.hairpin_queue_setup)
> +
s/tx.hairpin_queue_setup/tx_hairpin_queue_setup/ ?
<...>
> diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
> index 39250b5da1..f5c0865023 100644
> --- a/lib/ethdev/meson.build
> +++ b/lib/ethdev/meson.build
> @@ -24,6 +24,7 @@ headers = files(
> 'rte_ethdev.h',
> 'rte_ethdev_trace.h',
> 'rte_ethdev_trace_fp.h',
> + 'rte_ethdev_trace_fp_burst.h',
Why these trace headers are public?
Aren't trace points only used by the APIs, so I expect them to be
internal, so applications shouldn't need them. Why they are expsed to user.
@David, what do you think?
<...>
> @@ -258,6 +259,7 @@ rte_eth_iterator_init(struct rte_dev_iterator *iter, const char *devargs_str)
>
> end:
> iter->cls = rte_class_find_by_name("eth");
> + rte_eth_trace_iterator_init(devargs_str);
> rte_devargs_reset(&devargs);
> return 0;
Why not add trace call just before return, as a separate block, like:
``
end:
iter->cls = rte_class_find_by_name("eth");
rte_devargs_reset(&devargs);
rte_eth_trace_iterator_init(devargs_str);
return 0;
``
>
> @@ -274,6 +276,8 @@ rte_eth_iterator_init(struct rte_dev_iterator *iter, const char *devargs_str)
> uint16_t
> rte_eth_iterator_next(struct rte_dev_iterator *iter)
> {
> + uint16_t id;
> +
> if (iter == NULL) {
> RTE_ETHDEV_LOG(ERR,
> "Cannot get next device from NULL iterator\n");
> @@ -297,8 +301,11 @@ rte_eth_iterator_next(struct rte_dev_iterator *iter)
> /* A device is matching bus part, need to check ethdev part. */
> iter->class_device = iter->cls->dev_iterate(
> iter->class_device, iter->cls_str, iter);
> - if (iter->class_device != NULL)
> - return eth_dev_to_id(iter->class_device); /* match */
> + if (iter->class_device != NULL) {
> + id = eth_dev_to_id(iter->class_device);
> + rte_eth_trace_iterator_next(iter, id);
> + return id; /* match */
please move 'id' declaration within the if block, and again put trace
call into separate block to highlight it, otherwise easy to miss, like:
``
if (iter->class_device != NULL) {
uint16_t id = eth_dev_to_id(iter->class_device);
rte_eth_trace_iterator_next(iter, id);
return id; /* match */
}
> + }
> } while (iter->bus != NULL); /* need to try next rte_device */
>
> /* No more ethdev port to iterate. */
> @@ -316,6 +323,7 @@ rte_eth_iterator_cleanup(struct rte_dev_iterator *iter)
>
> if (iter->bus_str == NULL)
> return; /* nothing to free in pure class filter */
> + rte_eth_trace_iterator_cleanup(iter);
Can you please make trace call a separate block, I won't comment same
for bellow, can you please apply this to all.
> free(RTE_CAST_FIELD(iter, bus_str, char *)); /* workaround const */
> free(RTE_CAST_FIELD(iter, cls_str, char *)); /* workaround const */
> memset(iter, 0, sizeof(*iter));
> @@ -324,12 +332,18 @@ rte_eth_iterator_cleanup(struct rte_dev_iterator *iter)
> uint16_t
> rte_eth_find_next(uint16_t port_id)
> {
> + rte_eth_trace_find_next(port_id);
> +
Why tracing previous port_id, and other one below records next port_id,
won't it be confusing to have both with same name.
I suggest just keep last one, (next port_id).
> while (port_id < RTE_MAX_ETHPORTS &&
> rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED)
> port_id++;
>
> - if (port_id >= RTE_MAX_ETHPORTS)
> + if (port_id >= RTE_MAX_ETHPORTS) {
> + rte_eth_trace_find_next(RTE_MAX_ETHPORTS);
Is there a specific reason to trace all paths, why not just keep the
last one?
> return RTE_MAX_ETHPORTS;
> + }
> +
> + rte_eth_trace_find_next(port_id);
>
> return port_id;
> }
> @@ -347,10 +361,15 @@ uint16_t
> rte_eth_find_next_of(uint16_t port_id, const struct rte_device *parent)
> {
> port_id = rte_eth_find_next(port_id);
> +
> + rte_eth_trace_find_next_of(port_id);
> +
> while (port_id < RTE_MAX_ETHPORTS &&
> rte_eth_devices[port_id].device != parent)
> port_id = rte_eth_find_next(port_id + 1);
>
> + rte_eth_trace_find_next_of(port_id);
> +
Same here, lets keep only the last one.
> return port_id;
> }
>
> @@ -358,6 +377,9 @@ uint16_t
> rte_eth_find_next_sibling(uint16_t port_id, uint16_t ref_port_id)
> {
> RTE_ETH_VALID_PORTID_OR_ERR_RET(ref_port_id, RTE_MAX_ETHPORTS);
> +
> + rte_eth_trace_find_next_sibling(port_id, ref_port_id);
> +
This doesn't record the return values, function should be updated to
keep the interim return value of 'rte_eth_find_next_of()' and trace
functions should record it.
> return rte_eth_find_next_of(port_id,
> rte_eth_devices[ref_port_id].device);
> }
> @@ -372,10 +394,13 @@ int
> rte_eth_dev_is_valid_port(uint16_t port_id)
> {
> if (port_id >= RTE_MAX_ETHPORTS ||
> - (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED))
> + (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED)) {
> + rte_ethdev_trace_is_valid_port(port_id, 0);
> return 0;
> - else
> + } else {
> + rte_ethdev_trace_is_valid_port(port_id, 1);
> return 1;
> + }
What about to create an interim 'is_valid' variable and record it with
single trace call?
<...>
> uint32_t
> rte_eth_speed_bitflag(uint32_t speed, int duplex)
> {
> + rte_eth_trace_speed_bitflag(speed, duplex);
Let's create an interim return value and record it for the trace
function, and please move trace function to the bottom of the function.
<...>
> @@ -2433,6 +2529,7 @@ void
> rte_eth_tx_buffer_drop_callback(struct rte_mbuf **pkts, uint16_t unsent,
> void *userdata __rte_unused)
> {
> + rte_eth_trace_tx_buffer_drop_callback(pkts, unsent);
Since only pointer value is recorded, function can be moved down, please
put emtpy line in between.
<...>
> @@ -2495,7 +2598,12 @@ rte_eth_tx_done_cleanup(uint16_t port_id, uint16_t queue_id, uint32_t free_cnt)
> /* Call driver to free pending mbufs. */
> ret = (*dev->dev_ops->tx_done_cleanup)(dev->data->tx_queues[queue_id],
> free_cnt);
> - return eth_err(port_id, ret);
> +
> + ret = eth_err(port_id, ret);
Please don't add new empty line _before_ this functions.
<...>
> @@ -2700,6 +2834,8 @@ rte_eth_link_to_str(char *str, size_t len, const struct rte_eth_link *eth_link)
> return -EINVAL;
> }
>
> + rte_eth_trace_link_to_str(len, eth_link);
> +
Why not record return value and move trace function to the end of the
function and record 'str' too.
> if (eth_link->link_status == RTE_ETH_LINK_DOWN)
> return snprintf(str, len, "Link down");
> else
> @@ -2715,6 +2851,7 @@ int
> rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats)
> {
> struct rte_eth_dev *dev;
> + int ret;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
> @@ -2730,7 +2867,12 @@ rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats)
> if (*dev->dev_ops->stats_get == NULL)
> return -ENOTSUP;
> stats->rx_nombuf = dev->data->rx_mbuf_alloc_failed;
> - return eth_err(port_id, (*dev->dev_ops->stats_get)(dev, stats));
> +
> + ret = eth_err(port_id, (*dev->dev_ops->stats_get)(dev, stats));
Pleaes don't add empyt line above.
<...>
> @@ -3229,13 +3384,19 @@ int
> rte_eth_xstats_reset(uint16_t port_id)
> {
> struct rte_eth_dev *dev;
> + int ret;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
>
> /* implemented by the driver */
> - if (dev->dev_ops->xstats_reset != NULL)
> - return eth_err(port_id, (*dev->dev_ops->xstats_reset)(dev));
> + if (dev->dev_ops->xstats_reset != NULL) {
> + ret = eth_err(port_id, (*dev->dev_ops->xstats_reset)(dev));
Can you please move 'ret' decleration in if block.
``
int ret = eth_err(port_id, (*dev->dev_ops->xstats_reset)(dev));
``
> +
> + rte_eth_trace_xstats_reset(port_id, ret);
> +
> + return ret;
> + }
>
> /* fallback to default */
> return rte_eth_stats_reset(port_id);
> @@ -3268,24 +3429,37 @@ int
> rte_eth_dev_set_tx_queue_stats_mapping(uint16_t port_id, uint16_t tx_queue_id,
> uint8_t stat_idx)
> {
> - return eth_err(port_id, eth_dev_set_queue_stats_mapping(port_id,
> + int ret;
> +
> + ret = eth_err(port_id, eth_dev_set_queue_stats_mapping(port_id,
> tx_queue_id,
> stat_idx, STAT_QMAP_TX));
> +
> + rte_ethdev_trace_set_tx_queue_stats_mapping(port_id, tx_queue_id, stat_idx, ret);
> +
In below function 'rte_ethdev_trace_set_rx_queue_stats_mapping()' call
wrapped to fit 80 lines, but this one not, please be consistent and if
possible break both to fit as done below.
<...>
> +RTE_TRACE_POINT(
> + rte_eth_trace_iterator_next,
> + RTE_TRACE_POINT_ARGS(struct rte_dev_iterator *iter, uint16_t id),
> + rte_trace_point_emit_ptr(iter);
> + rte_trace_point_emit_string(iter->bus_str);
> + rte_trace_point_emit_string(iter->cls_str);
> + rte_trace_point_emit_u16(id);
> +)
> +
Trace functions don't chage parameters, what do you think to update all
parameters with 'const' keywords for this:
``
RTE_TRACE_POINT(
rte_eth_trace_iterator_next,
RTE_TRACE_POINT_ARGS(const struct rte_dev_iterator *iter, uint16_t id),
rte_trace_point_emit_ptr(iter);
rte_trace_point_emit_string(iter->bus_str);
rte_trace_point_emit_string(iter->cls_str);
rte_trace_point_emit_u16(id);
)
``
This comment is not just for this trace point, but for *all* trace points.
<...>
> +RTE_TRACE_POINT(
> + rte_eth_trace_rx_hairpin_queue_setup,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, uint16_t rx_queue_id,
> + uint16_t nb_rx_desc, const struct rte_eth_hairpin_conf *conf,
> + int ret),
> + uint32_t peer_count = conf->peer_count;
> + uint32_t tx_explicit = conf->tx_explicit;
> + uint32_t manual_bind = conf->manual_bind;
> + uint32_t use_locked_device_memory = conf->use_locked_device_memory;
> + uint32_t use_rte_memory = conf->use_rte_memory;
> + uint32_t force_memory = conf->force_memory;
> +
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_u16(rx_queue_id);
> + rte_trace_point_emit_u16(nb_rx_desc);
> + rte_trace_point_emit_ptr(conf);
> + rte_trace_point_emit_u32(peer_count);
> + rte_trace_point_emit_u32(tx_explicit);
> + rte_trace_point_emit_u32(manual_bind);
> + rte_trace_point_emit_u32(use_locked_device_memory);
> + rte_trace_point_emit_u32(use_rte_memory);
> + rte_trace_point_emit_u32(force_memory);
> + rte_trace_point_emit_int(ret);
Do we need temporary variables like 'peer_count', why not directly use them:
``
rte_trace_point_emit_u32(conf->peer_count);
``
> +)
> +
> +RTE_TRACE_POINT(
> + rte_eth_trace_tx_hairpin_queue_setup,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, uint16_t tx_queue_id,
> + uint16_t nb_tx_desc, const struct rte_eth_hairpin_conf *conf,
> + int ret),
> + uint32_t peer_count = conf->peer_count;
> + uint32_t tx_explicit = conf->tx_explicit;
> + uint32_t manual_bind = conf->manual_bind;
> + uint32_t use_locked_device_memory = conf->use_locked_device_memory;
> + uint32_t use_rte_memory = conf->use_rte_memory;
> + uint32_t force_memory = conf->force_memory;
> +
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_u16(tx_queue_id);
> + rte_trace_point_emit_u16(nb_tx_desc);
> + rte_trace_point_emit_ptr(conf);
> + rte_trace_point_emit_u32(peer_count);
> + rte_trace_point_emit_u32(tx_explicit);
> + rte_trace_point_emit_u32(manual_bind);
> + rte_trace_point_emit_u32(use_locked_device_memory);
> + rte_trace_point_emit_u32(use_rte_memory);
> + rte_trace_point_emit_u32(force_memory);
> + rte_trace_point_emit_int(ret);
> +)
Same as above.
<...>
> +RTE_TRACE_POINT(
> + rte_eth_trace_allmulticast_disable,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, int all_multicast, int diag),
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_int(all_multicast);
> + rte_trace_point_emit_int(diag);
> +)
> +
Can you replace 'diag' with 'ret' for consistency, same for
'*promiscuous/allmulticast_enable/disable'.
<...>
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_find_next,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id),
> + rte_trace_point_emit_u16(port_id);
> +)
> +
Why 'rte_eth_trace_find_next' added as fast path?
Can you please add comment for all why it is added as fast path, this
help to evaluate/review this later.
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_find_next_of,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id),
> + rte_trace_point_emit_u16(port_id);
> +)
> +
Why not record second parameter of the API, "struct rte_device *parent" too?
<...>
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_hairpin_get_peer_ports,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, uint16_t *peer_ports,
> + size_t len, uint32_t direction, int ret),
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_ptr(peer_ports);
> + rte_trace_point_emit_size_t(len);
> + rte_trace_point_emit_u32(direction);
> + rte_trace_point_emit_int(ret);
> +)
> +
Some of these functions I am not clear why fast path trace point is
used, 'rte_eth_trace_hairpin_get_peer_ports' is one of them, can you
please comment the justification to the code as suggested above.
<...>
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_link_get,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, struct rte_eth_link *link),
> + uint16_t link_duplex = link->link_duplex;
> + uint16_t link_autoneg = link->link_autoneg;
> + uint16_t link_status = link->link_status;
> +
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_u32(link->link_speed);
> + rte_trace_point_emit_u16(link_duplex);
> + rte_trace_point_emit_u16(link_autoneg);
> + rte_trace_point_emit_u16(link_status);
> +)
Why creating varible for 'link_duplex' for 'link->link_duplex' but using
'link->link_speed', why not use all as 'link->xxx'?
<...>
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_xstats_get_names,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id,
> + struct rte_eth_xstat_name *xstats_names,
> + unsigned int size, int cnt_used_entries),
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_string(xstats_names->name);
> + rte_trace_point_emit_u32(size);
> + rte_trace_point_emit_int(cnt_used_entries);
> +)
> +
'xstats_names' is an array, whose size is 'cnt_used_entries', just
printing 'xstats_names->name' for first element can be misleading,
can print all values as done in 'rte_eth_xstats_get()'
<...>
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_xstats_get,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, struct rte_eth_xstat xstats,
> + int i),
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_u64(xstats.id);
> + rte_trace_point_emit_u64(xstats.value);
> + rte_trace_point_emit_u32(i);
> +)
> +
as far as I can see "id == i", so maybe 'i' can be dropped.
<...>
> @@ -298,6 +298,72 @@ EXPERIMENTAL {
> rte_flow_get_q_aged_flows;
> rte_mtr_meter_policy_get;
> rte_mtr_meter_profile_get;
> +
> + # added in 23.03
> + __rte_eth_trace_allmulticast_disable;
> + __rte_eth_trace_allmulticast_enable;
> + __rte_eth_trace_allmulticast_get;
> + __rte_eth_trace_call_rx_callbacks;
> + __rte_eth_trace_call_tx_callbacks;
> + __rte_eth_trace_find_next;
> + __rte_eth_trace_find_next_of;
> + __rte_eth_trace_find_next_owned_by;
> + __rte_eth_trace_find_next_sibling;
> + __rte_eth_trace_hairpin_bind;
> + __rte_eth_trace_hairpin_get_peer_ports;
> + __rte_eth_trace_hairpin_unbind;
> + __rte_eth_trace_iterator_cleanup;
> + __rte_eth_trace_iterator_init;
> + __rte_eth_trace_iterator_next;
> + __rte_eth_trace_link_get;
> + __rte_eth_trace_link_get_nowait;
> + __rte_eth_trace_link_speed_to_str;
> + __rte_eth_trace_link_to_str;
> + __rte_eth_trace_promiscuous_disable;
> + __rte_eth_trace_promiscuous_enable;
> + __rte_eth_trace_promiscuous_get;
> + __rte_eth_trace_rx_hairpin_queue_setup;
> + __rte_eth_trace_speed_bitflag;
> + __rte_eth_trace_stats_get;
> + __rte_eth_trace_stats_reset;
> + __rte_eth_trace_tx_buffer_count_callback;
> + __rte_eth_trace_tx_buffer_drop_callback;
> + __rte_eth_trace_tx_buffer_init;
> + __rte_eth_trace_tx_buffer_set_err_callback;
> + __rte_eth_trace_tx_done_cleanup;
> + __rte_eth_trace_tx_hairpin_queue_setup;
> + __rte_eth_trace_xstats_get;
> + __rte_eth_trace_xstats_get_by_id;
> + __rte_eth_trace_xstats_get_id_by_name;
> + __rte_eth_trace_xstats_get_names;
> + __rte_eth_trace_xstats_get_names_by_id;
> + __rte_eth_trace_xstats_reset;
> + __rte_ethdev_trace_capability_name;
> + __rte_ethdev_trace_count_avail;
> + __rte_ethdev_trace_count_total;
> + __rte_ethdev_trace_fw_version_get;
> + __rte_ethdev_trace_get_name_by_port;
> + __rte_ethdev_trace_get_port_by_name;
> + __rte_ethdev_trace_get_sec_ctx;
> + __rte_ethdev_trace_is_removed;
> + __rte_ethdev_trace_is_valid_port;
> + __rte_ethdev_trace_owner_delete;
> + __rte_ethdev_trace_owner_get;
> + __rte_ethdev_trace_owner_new;
> + __rte_ethdev_trace_owner_set;
> + __rte_ethdev_trace_owner_unset;
> + __rte_ethdev_trace_reset;
> + __rte_ethdev_trace_rx_offload_name;
> + __rte_ethdev_trace_rx_queue_start;
> + __rte_ethdev_trace_rx_queue_stop;
> + __rte_ethdev_trace_set_link_down;
> + __rte_ethdev_trace_set_link_up;
> + __rte_ethdev_trace_set_rx_queue_stats_mapping;
> + __rte_ethdev_trace_set_tx_queue_stats_mapping;
> + __rte_ethdev_trace_socket_id;
> + __rte_ethdev_trace_tx_offload_name;
> + __rte_ethdev_trace_tx_queue_start;
> + __rte_ethdev_trace_tx_queue_stop;
Can you please drop these trace objects?
next prev parent reply other threads:[~2023-01-23 17:29 UTC|newest]
Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-04 13:44 [PATCH 0/6] add trace points in ethdev library Ankur Dwivedi
2022-08-04 13:44 ` [PATCH 1/6] ethdev: add trace points Ankur Dwivedi
2022-09-12 11:00 ` Andrew Rybchenko
2022-09-13 6:48 ` [EXT] " Ankur Dwivedi
2022-09-13 7:18 ` Andrew Rybchenko
2022-09-26 15:03 ` Andrew Rybchenko
2022-09-28 4:02 ` Jerin Jacob
2022-08-04 13:44 ` [PATCH 2/6] ethdev: add trace points for flow Ankur Dwivedi
2022-08-04 13:44 ` [PATCH 3/6] ethdev: add trace points for mtr Ankur Dwivedi
2022-08-04 13:44 ` [PATCH 4/6] ethdev: add trace points for tm Ankur Dwivedi
2022-08-04 13:44 ` [PATCH 5/6] ethdev: add trace points for driver Ankur Dwivedi
2022-08-04 13:44 ` [PATCH 6/6] devtools: add trace function check in checkpatch Ankur Dwivedi
2022-09-29 10:29 ` [PATCH v2 0/4] add trace points in ethdev library Ankur Dwivedi
2022-09-29 10:29 ` [PATCH v2 1/4] ethdev: add trace points Ankur Dwivedi
2022-10-06 7:09 ` Andrew Rybchenko
2022-10-06 7:24 ` [EXT] " Ankur Dwivedi
2022-10-06 7:27 ` Andrew Rybchenko
2022-10-06 7:43 ` Ankur Dwivedi
2022-10-06 7:50 ` Andrew Rybchenko
2022-10-06 7:57 ` David Marchand
2022-10-12 9:49 ` Jerin Jacob
2022-10-12 9:56 ` David Marchand
2022-09-29 10:29 ` [PATCH v2 2/4] ethdev: add trace points for flow Ankur Dwivedi
2022-09-29 10:29 ` [PATCH v2 3/4] ethdev: add trace points for mtr Ankur Dwivedi
2022-09-29 10:29 ` [PATCH v2 4/4] ethdev: add trace points for tm Ankur Dwivedi
2022-10-06 7:10 ` [PATCH v2 0/4] add trace points in ethdev library Andrew Rybchenko
2022-10-06 7:26 ` [EXT] " Ankur Dwivedi
2022-10-06 7:28 ` Andrew Rybchenko
2022-10-06 7:47 ` Ankur Dwivedi
2022-10-06 12:55 ` Ankur Dwivedi
2022-10-06 15:18 ` [PATCH v3 " Ankur Dwivedi
2022-10-06 15:18 ` [PATCH v3 1/4] ethdev: add trace points Ankur Dwivedi
2022-10-06 16:03 ` Morten Brørup
2022-10-07 16:23 ` Ankur Dwivedi
2022-10-10 6:39 ` Ankur Dwivedi
2022-12-12 18:34 ` Ferruh Yigit
2022-12-12 18:38 ` Ferruh Yigit
2022-12-14 10:34 ` David Marchand
2022-12-14 11:04 ` Ferruh Yigit
2022-12-13 20:06 ` Ferruh Yigit
2022-12-14 10:40 ` Jerin Jacob
2022-12-14 12:10 ` Ferruh Yigit
2022-12-15 6:49 ` Jerin Jacob
2023-01-12 9:10 ` Thomas Monjalon
2023-01-12 9:43 ` trace point symbols Morten Brørup
2023-01-13 11:22 ` Jerin Jacob
2022-12-14 13:52 ` [EXT] Re: [PATCH v3 1/4] ethdev: add trace points Ankur Dwivedi
2022-10-06 15:18 ` [PATCH v3 2/4] ethdev: add trace points for flow Ankur Dwivedi
2022-10-06 15:18 ` [PATCH v3 3/4] ethdev: add trace points for mtr Ankur Dwivedi
2022-10-06 15:18 ` [PATCH v3 4/4] ethdev: add trace points for tm Ankur Dwivedi
2022-12-22 6:32 ` [PATCH v4 0/6] add trace points in ethdev library Ankur Dwivedi
2022-12-22 6:33 ` [PATCH v4 1/6] eal: trace: add trace point emit for array Ankur Dwivedi
2022-12-22 9:06 ` Sunil Kumar Kori
2022-12-22 10:32 ` Morten Brørup
2022-12-22 15:18 ` Ankur Dwivedi
2022-12-22 6:33 ` [PATCH v4 2/6] ethdev: add trace points for ethdev Ankur Dwivedi
2022-12-22 10:50 ` Morten Brørup
2022-12-22 6:33 ` [PATCH v4 3/6] ethdev: add trace points for remaining functions Ankur Dwivedi
2022-12-22 6:33 ` [PATCH v4 4/6] ethdev: add trace points for flow Ankur Dwivedi
2022-12-22 6:33 ` [PATCH v4 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2022-12-22 6:33 ` [PATCH v4 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-01-12 11:21 ` [PATCH v5 0/6] add trace points in ethdev library Ankur Dwivedi
2023-01-12 11:21 ` [PATCH v5 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-01-12 12:38 ` Morten Brørup
2023-01-12 13:22 ` Ankur Dwivedi
2023-01-12 16:29 ` Sunil Kumar Kori
2023-01-12 16:43 ` Sunil Kumar Kori
2023-01-12 11:21 ` [PATCH v5 2/6] ethdev: add trace points for ethdev Ankur Dwivedi
2023-01-12 16:34 ` Sunil Kumar Kori
2023-01-12 11:21 ` [PATCH v5 3/6] ethdev: add trace points for remaining functions Ankur Dwivedi
2023-01-12 16:38 ` Sunil Kumar Kori
2023-01-13 6:31 ` Ankur Dwivedi
2023-01-13 8:11 ` Sunil Kumar Kori
2023-01-12 11:21 ` [PATCH v5 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-01-12 11:21 ` [PATCH v5 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-01-12 11:21 ` [PATCH v5 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-01-12 17:03 ` [PATCH v5 0/6] add trace points in ethdev library Ferruh Yigit
2023-01-13 6:32 ` [EXT] " Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 " Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-01-20 10:11 ` Morten Brørup
2023-01-23 17:27 ` Ferruh Yigit
2023-01-25 15:02 ` [EXT] " Ankur Dwivedi
2023-01-25 16:09 ` Ferruh Yigit
2023-01-30 13:35 ` Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 2/6] ethdev: add trace points for ethdev (part one) Ankur Dwivedi
2023-01-23 17:28 ` Ferruh Yigit [this message]
2023-01-30 16:01 ` [EXT] " Ankur Dwivedi
2023-01-31 18:38 ` Ferruh Yigit
2023-01-31 18:46 ` Jerin Jacob
2023-01-31 22:20 ` Ferruh Yigit
2023-02-01 8:31 ` Jerin Jacob
2023-02-01 10:50 ` Ferruh Yigit
2023-02-01 15:42 ` Ankur Dwivedi
2023-02-02 8:56 ` Ferruh Yigit
2023-02-02 10:20 ` Ankur Dwivedi
2023-02-02 12:52 ` Ferruh Yigit
2023-02-02 13:40 ` Ankur Dwivedi
2023-02-02 13:44 ` Ferruh Yigit
2023-02-02 13:53 ` Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 3/6] ethdev: add trace points for ethdev (part two) Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-01-23 9:02 ` [PATCH v7 0/6] add trace points in ethdev library Ankur Dwivedi
2023-01-23 9:02 ` [PATCH v7 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-01-23 13:01 ` Jerin Jacob
2023-01-23 13:08 ` Morten Brørup
2023-01-23 13:39 ` Ankur Dwivedi
2023-01-30 7:30 ` Sunil Kumar Kori
2023-01-30 8:15 ` Morten Brørup
2023-01-30 8:40 ` Sunil Kumar Kori
2023-01-23 9:02 ` [PATCH v7 2/6] ethdev: add trace points for ethdev (part one) Ankur Dwivedi
2023-01-30 8:45 ` Sunil Kumar Kori
2023-01-23 9:02 ` [PATCH v7 3/6] ethdev: add trace points for ethdev (part two) Ankur Dwivedi
2023-01-30 8:47 ` Sunil Kumar Kori
2023-01-23 9:02 ` [PATCH v7 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-02-02 13:52 ` Ori Kam
2023-02-02 13:56 ` Ori Kam
2023-02-02 15:45 ` Ankur Dwivedi
2023-01-23 9:02 ` [PATCH v7 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-01-30 8:50 ` Sunil Kumar Kori
2023-01-23 9:02 ` [PATCH v7 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 0/6] add trace points in ethdev library Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-02-06 14:48 ` David Marchand
2023-02-07 5:08 ` [EXT] " Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 2/6] ethdev: add trace points for ethdev (part one) Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 3/6] ethdev: add trace points for ethdev (part two) Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-02-06 11:58 ` [PATCH v8 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-02-07 6:32 ` [PATCH v9 0/6] add trace points in ethdev library Ankur Dwivedi
2023-02-07 6:32 ` [PATCH v9 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-02-08 1:16 ` Ferruh Yigit
2023-02-07 6:32 ` [PATCH v9 2/6] ethdev: add trace points for ethdev (part one) Ankur Dwivedi
2023-02-08 1:16 ` Ferruh Yigit
2023-02-08 10:30 ` [EXT] " Ankur Dwivedi
2023-02-07 6:32 ` [PATCH v9 3/6] ethdev: add trace points for ethdev (part two) Ankur Dwivedi
2023-02-08 1:20 ` Ferruh Yigit
2023-02-08 10:42 ` [EXT] " Ankur Dwivedi
2023-02-08 11:00 ` Ferruh Yigit
2023-02-08 11:04 ` Ferruh Yigit
2023-02-08 14:15 ` Ankur Dwivedi
2023-02-08 15:05 ` Ferruh Yigit
2023-02-08 15:11 ` Ankur Dwivedi
2023-02-07 6:32 ` [PATCH v9 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-02-07 6:32 ` [PATCH v9 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-02-07 6:32 ` [PATCH v9 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-02-08 13:28 ` [PATCH v10 0/6] add trace points in ethdev library Ankur Dwivedi
2023-02-08 13:28 ` [PATCH v10 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-02-08 13:28 ` [PATCH v10 2/6] ethdev: add trace points for ethdev (part one) Ankur Dwivedi
2023-02-08 13:28 ` [PATCH v10 3/6] ethdev: add trace points for ethdev (part two) Ankur Dwivedi
2023-02-08 13:28 ` [PATCH v10 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-02-08 16:15 ` Ori Kam
2023-02-08 13:28 ` [PATCH v10 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-02-08 13:28 ` [PATCH v10 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-03-15 7:14 ` Yuan, DukaiX
2023-03-16 9:58 ` Ankur Dwivedi
2023-02-08 17:12 ` [PATCH v11 0/6] add trace points in ethdev library Ankur Dwivedi
2023-02-08 17:12 ` [PATCH v11 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-02-08 17:12 ` [PATCH v11 2/6] ethdev: add trace points for ethdev (part one) Ankur Dwivedi
2023-02-17 7:32 ` Li, WeiyuanX
2023-02-08 17:12 ` [PATCH v11 3/6] ethdev: add trace points for ethdev (part two) Ankur Dwivedi
2023-02-08 20:09 ` Ferruh Yigit
2023-02-08 17:12 ` [PATCH v11 4/6] ethdev: add trace points for flow Ankur Dwivedi
2023-02-08 17:12 ` [PATCH v11 5/6] ethdev: add trace points for mtr Ankur Dwivedi
2023-02-08 17:12 ` [PATCH v11 6/6] ethdev: add trace points for tm Ankur Dwivedi
2023-02-08 20:09 ` [PATCH v11 0/6] add trace points in ethdev library Ferruh Yigit
2023-02-26 18:34 ` Ali Alnubani
2023-02-27 9:38 ` Ankur Dwivedi
2023-01-23 17:30 ` [PATCH v6 " Ferruh Yigit
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=614e22c6-8485-0e8d-742e-b3d100f96468@amd.com \
--to=ferruh.yigit@amd.com \
--cc=Yuying.Zhang@intel.com \
--cc=aboyer@pensando.io \
--cc=adwivedi@marvell.com \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=apeksha.gupta@nxp.com \
--cc=beilei.xing@intel.com \
--cc=bruce.richardson@intel.com \
--cc=chandu@amd.com \
--cc=chaoyong.he@corigine.com \
--cc=chas3@att.com \
--cc=chenbo.xia@intel.com \
--cc=ciara.loftus@intel.com \
--cc=cloud.wangxiaoyun@huawei.com \
--cc=cristian.dumitrescu@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dsinghrawat@marvell.com \
--cc=ed.czeck@atomicrules.com \
--cc=evgenys@amazon.com \
--cc=g.singh@nxp.com \
--cc=grive@u256.net \
--cc=hemant.agrawal@nxp.com \
--cc=hkalra@marvell.com \
--cc=humin29@huawei.com \
--cc=hyonkim@cisco.com \
--cc=igorch@amazon.com \
--cc=irusskikh@marvell.com \
--cc=jasvinder.singh@intel.com \
--cc=jbehrens@vmware.com \
--cc=jerinj@marvell.com \
--cc=jgrajcia@cisco.com \
--cc=jianwang@trustnetic.com \
--cc=jiawenwu@trustnetic.com \
--cc=jingjing.wu@intel.com \
--cc=john.miller@atomicrules.com \
--cc=johndale@cisco.com \
--cc=junfeng.guo@intel.com \
--cc=kirankumark@marvell.com \
--cc=linville@tuxdriver.com \
--cc=lironh@marvell.com \
--cc=liudongdong3@huawei.com \
--cc=longli@microsoft.com \
--cc=matan@nvidia.com \
--cc=matt.peters@windriver.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=mczekaj@marvell.com \
--cc=mdr@ashroe.eu \
--cc=mk@semihalf.com \
--cc=mtetsuyah@gmail.com \
--cc=mw@semihalf.com \
--cc=ndabilpuram@marvell.com \
--cc=niklas.soderlund@corigine.com \
--cc=orika@nvidia.com \
--cc=qi.z.zhang@intel.com \
--cc=qiming.yang@intel.com \
--cc=radhac@marvell.com \
--cc=rahul.lakkireddy@chelsio.com \
--cc=rmody@marvell.com \
--cc=rosen.xu@intel.com \
--cc=sachin.saxena@nxp.com \
--cc=sachin.saxena@oss.nxp.com \
--cc=sedara@marvell.com \
--cc=shaibran@amazon.com \
--cc=shepard.siegel@atomicrules.com \
--cc=shshaikh@marvell.com \
--cc=simei.su@intel.com \
--cc=skori@marvell.com \
--cc=skoteshwar@marvell.com \
--cc=somnath.kotur@broadcom.com \
--cc=spinler@cesnet.cz \
--cc=srinivasan@marvell.com \
--cc=steven.webster@windriver.com \
--cc=sthotton@marvell.com \
--cc=thomas@monjalon.net \
--cc=vburru@marvell.com \
--cc=viacheslavo@nvidia.com \
--cc=wenjun1.wu@intel.com \
--cc=xiao.w.wang@intel.com \
--cc=xuanziyang2@huawei.com \
--cc=yisen.zhuang@huawei.com \
--cc=zhouguoyang@huawei.com \
--cc=zr@semihalf.com \
/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).