From: Chaoyong He <chaoyong.he@corigine.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: oss-drivers <oss-drivers@corigine.com>
Subject: RE: [PATCH v2 0/7] add trace support for control message
Date: Tue, 9 Jul 2024 03:16:37 +0000 [thread overview]
Message-ID: <SJ0PR13MB5545DF9C69F655D9FB8CAB6B9EDB2@SJ0PR13MB5545.namprd13.prod.outlook.com> (raw)
In-Reply-To: <3e2fe3a9-8923-4dcd-b230-5d2280f58e96@amd.com>
> On 7/8/2024 3:45 AM, Chaoyong He wrote:
> > This patch series add trace support for control message send to flower
> > firmware.
> >
> > ---
> > v2: rebase to the latest main branch.
> > ---
> >
> > Chaoyong He (7):
> > net/nfp: add trace points about port
> > net/nfp: add trace point about tunnel
> > net/nfp: add trace point about Qos
> > net/nfp: refactor to prepare for add flow trace point
> > net/nfp: add trace point about flow rule
> > net/nfp: add trace point about flow rule pattern
> > net/nfp: add trace point about flow rule action
> >
>
> Still getting some github action errors, can you please check:
> https://github.com/ferruhy/dpdk/actions/runs/9838241137
In short, after some debug, seems we are not using the 'trace' library as its expect, so we decide to abandon this patch series.
For details:
# The way we debug:
```
/home/hcy/dpdk-next-net-private/build/app/dpdk-testpmd -c 3 --no-huge -m 40 -d build/drivers -a 0:0.0 --vdev ne
```
# The back trace when problem occurs:
```
(gdb) bt
#0 rte_pmd_nfp_trace_cmsg_flow_pattern_meta_tci (cmsg=0x3) at ../drivers/net/nfp/nfp_trace.h:239
#1 0x00007ffff7c81879 in __rte_trace_point_register (
handle=0x7ffff02c5c98 <__rte_pmd_nfp_trace_cmsg_flow_pattern_meta_tci>,
name=0x7ffff02b36c0 <__rte_pmd_nfp_trace_cmsg_flow_pattern_meta_tci_name> "pmd.net.nfp.cmsg.flow.pattern.meta_tci", register_fn=0x7ffff029ce8c <rte_pmd_nfp_trace_cmsg_flow_pattern_meta_tci>)
at ../lib/eal/common/eal_common_trace.c:480
#2 0x00007ffff029eb0f in rte_pmd_nfp_trace_cmsg_flow_pattern_meta_tci_init ()
at ../drivers/net/nfp/nfp_trace.c:43
#3 0x00007ffff7fd11ae in call_init (env=0x7fffffffdeb0, argv=0x7fffffffde48, argc=12,
l=<optimized out>) at dl-init.c:70
#4 call_init (l=<optimized out>, argc=12, argv=0x7fffffffde48, env=0x7fffffffdeb0) at dl-init.c:26
#5 0x00007ffff7fd129c in _dl_init (main_map=0x716e10, argc=12, argv=0x7fffffffde48, env=0x7fffffffdeb0)
at dl-init.c:117
#6 0x00007ffff15cef65 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>,
args=<optimized out>) at /usr/src/debug/glibc-2.34-60.el9.x86_64/elf/dl-error-skeleton.c:182
#7 0x00007ffff7fd7cbe in dl_open_worker (a=a@entry=0x7fffffffd730) at dl-open.c:803
#8 0x00007ffff15cef08 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>,
args=<optimized out>) at /usr/src/debug/glibc-2.34-60.el9.x86_64/elf/dl-error-skeleton.c:208
#9 0x00007ffff7fd804f in _dl_open (file=<optimized out>, mode=-2147483646,
caller_dlopen=0x7ffff7c66e15 <eal_dlopen+318>, nsid=-2, argc=12, argv=0x7fffffffde48,
env=0x7fffffffdeb0) at dl-open.c:879
#10 0x00007ffff14d486c in dlopen_doit (a=a@entry=0x7fffffffd9a0) at dlopen.c:56
#11 0x00007ffff15cef08 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffd900,
operate=<optimized out>, args=<optimized out>)
at /usr/src/debug/glibc-2.34-60.el9.x86_64/elf/dl-error-skeleton.c:208
#12 0x00007ffff15cefd3 in __GI__dl_catch_error (objname=0x7fffffffd958, errstring=0x7fffffffd960,
mallocedp=0x7fffffffd957, operate=<optimized out>, args=<optimized out>)
at /usr/src/debug/glibc-2.34-60.el9.x86_64/elf/dl-error-skeleton.c:227
#13 0x00007ffff14d433e in _dlerror_run (operate=operate@entry=0x7ffff14d4810 <dlopen_doit>,
args=args@entry=0x7fffffffd9a0) at dlerror.c:138
#14 0x00007ffff14d4921 in dlopen_implementation (dl_caller=<optimized out>, mode=<optimized out>,
file=<optimized out>) at dlopen.c:71
#15 ___dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:81
#16 0x00007ffff7c66e15 in eal_dlopen (pathname=0x6439f0 "build/drivers/librte_net_nfp.so")
at ../lib/eal/common/eal_common_options.c:506
#17 0x00007ffff7c670ff in eal_plugins_init () at ../lib/eal/common/eal_common_options.c:580
#18 0x00007ffff7c8a03c in rte_eal_init (argc=12, argv=0x7fffffffde48) at ../lib/eal/linux/eal.c:1015
#19 0x00000000004bb305 in main (argc=12, argv=0x7fffffffde48) at ../app/test-pmd/testpmd.c:4553
```
# The logic which cause the problem:
```
int
__rte_trace_point_register(rte_trace_point_t *handle, const char *name,
void (*register_fn)(void))
{
struct trace_point *tp;
uint16_t sz;
/* Sanity checks of arguments */
if (name == NULL || register_fn == NULL || handle == NULL) {
trace_err("invalid arguments");
rte_errno = EINVAL;
goto fail;
}
/* Check the size of the trace point object */
RTE_PER_LCORE(trace_point_sz) = 0;
register_fn(); // <---------- Here, call with empty parameter list
if (RTE_PER_LCORE(trace_point_sz) == 0) {
trace_err("missing rte_trace_emit_header() in register fn");
rte_errno = EBADF;
goto fail;
}
...
}
```
```
RTE_TRACE_POINT(
rte_pmd_nfp_trace_cmsg_flow_meta,
RTE_TRACE_POINT_ARGS(void *cmsg), // <--- Here, we need a parameter
struct nfp_fl_rule_metadata *meta = cmsg;
rte_trace_point_emit_u8(meta->key_len);
rte_trace_point_emit_u8(meta->mask_len);
rte_trace_point_emit_u8(meta->act_len);
rte_trace_point_emit_u8(meta->flags);
rte_trace_point_emit_u32(meta->host_ctx_id);
rte_trace_point_emit_u64(meta->host_cookie);
rte_trace_point_emit_u64(meta->flow_version);
rte_trace_point_emit_u32(meta->shortcut);
)
```
# Somehow, seems it get the parameter from the `rdi` register:
```
(gdb) info reg
rax 0x7ffff029ce8c 140737222659724
rbx 0x7ffff02c29d8 140737222814168
rcx 0x7ffff1246a40 140737239083584
rdx 0x7ffff124a000 140737239097344
rsi 0x7ffff12489e0 140737239091680
rdi 0x3 3
rbp 0x7fffffffd390 0x7fffffffd390
rsp 0x7fffffffd370 0x7fffffffd370
r8 0x0 0
r9 0x0 0
r10 0x8000 32768
r11 0x7ffff1633c80 140737243200640
r12 0x7fffffffde48 140737488346696
r13 0x7fffffffdeb0 140737488346800
r14 0x7ffff02c2a98 140737222814360
r15 0x0 0
rip 0x7ffff029ce98 0x7ffff029ce98 <rte_pmd_nfp_trace_cmsg_flow_pattern_meta_tci+12>
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
k0 0x2107c 135292
k1 0xfefe0000 4278059008
k2 0xffffbfff 4294950911
k3 0x0 0
k4 0x0 0
k5 0x0 0
k6 0x0 0
k7 0x0 0
```
# And the value in `rdi` register are never changed:
```
(gdb) frame 19
#19 0x00000000004bb305 in main (argc=12, argv=0x7fffffffde48) at ../app/test-pmd/testpmd.c:4553
4553 diag = rte_eal_init(argc, argv);
(gdb) info reg
rax 0x7ffff029ce8c 140737222659724
rbx 0x0 0
rcx 0x7ffff1246a40 140737239083584
rdx 0x7ffff124a000 140737239097344
rsi 0x7ffff12489e0 140737239091680
rdi 0x3 3
rbp 0x7fffffffdd30 0x7fffffffdd30
rsp 0x7fffffffdc30 0x7fffffffdc30
r8 0x0 0
r9 0x0 0
r10 0x8000 32768
r11 0x7ffff1633c80 140737243200640
r12 0x7fffffffde48 140737488346696
r13 0x4bb19c 4960668
r14 0x526ae0 5401312
r15 0x7ffff7ffd000 140737354125312
rip 0x4bb305 0x4bb305 <main+361>
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
k0 0x2107c 135292
k1 0xfefe0000 4278059008
k2 0xffffbfff 4294950911
k3 0x0 0
k4 0x0 0
k5 0x0 0
k6 0x0 0
k7 0x0 0
```
prev parent reply other threads:[~2024-07-09 3:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 10:07 [PATCH " Chaoyong He
2024-06-19 10:07 ` [PATCH 1/7] net/nfp: add trace points about port Chaoyong He
2024-06-19 10:07 ` [PATCH 2/7] net/nfp: add trace point about tunnel Chaoyong He
2024-06-19 10:07 ` [PATCH 3/7] net/nfp: add trace point about Qos Chaoyong He
2024-06-19 10:07 ` [PATCH 4/7] net/nfp: refactor to prepare for add flow trace point Chaoyong He
2024-06-19 10:07 ` [PATCH 5/7] net/nfp: add trace point about flow rule Chaoyong He
2024-06-19 10:07 ` [PATCH 6/7] net/nfp: add trace point about flow rule pattern Chaoyong He
2024-06-19 10:07 ` [PATCH 7/7] net/nfp: add trace point about flow rule action Chaoyong He
2024-07-07 22:43 ` [PATCH 0/7] add trace support for control message Ferruh Yigit
2024-07-08 1:42 ` Chaoyong He
2024-07-08 2:45 ` [PATCH v2 " Chaoyong He
2024-07-08 2:45 ` [PATCH v2 1/7] net/nfp: add trace points about port Chaoyong He
2024-07-08 2:45 ` [PATCH v2 2/7] net/nfp: add trace point about tunnel Chaoyong He
2024-07-08 2:45 ` [PATCH v2 3/7] net/nfp: add trace point about Qos Chaoyong He
2024-07-08 2:45 ` [PATCH v2 4/7] net/nfp: refactor to prepare for add flow trace point Chaoyong He
2024-07-08 2:45 ` [PATCH v2 5/7] net/nfp: add trace point about flow rule Chaoyong He
2024-07-08 2:45 ` [PATCH v2 6/7] net/nfp: add trace point about flow rule pattern Chaoyong He
2024-07-08 2:45 ` [PATCH v2 7/7] net/nfp: add trace point about flow rule action Chaoyong He
2024-07-08 11:45 ` [PATCH v2 0/7] add trace support for control message Ferruh Yigit
2024-07-09 1:15 ` Chaoyong He
2024-07-09 3:16 ` Chaoyong He [this message]
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=SJ0PR13MB5545DF9C69F655D9FB8CAB6B9EDB2@SJ0PR13MB5545.namprd13.prod.outlook.com \
--to=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=oss-drivers@corigine.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).