From: "Yan, Xiaoping (NSB - CN/Hangzhou)" <xiaoping.yan@nokia-sbell.com>
To: "tiwei.bie@intel.com" <tiwei.bie@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] interrupt mode issue for virtio device
Date: Sun, 2 Aug 2020 02:47:34 +0000 [thread overview]
Message-ID: <c561b344d05c4f55b4fafd9be45247f3@nokia-sbell.com> (raw)
In-Reply-To: <a05706c3a2fa4b5696d73c7b5db97495@nokia-sbell.com>
Hi,
It seems problem happen like this:
1. EAL init -> eth_virtio_pci_probe->…->rte_intr_efd_enable: eventfd (21) is created
2. event_register->rte_eth_dev_rx_intr_ctl_q: eventfd is added to epfd and elist
3. so far it is fine, but…
4. some operation (set link state, set mtu etc.) cause device restart, and another control thread of my application calls virtio_dev_configure
5. virtio_dev_configure-> virtio_init_device->…-> rte_intr_efd_enable: eventfd(34) is recreated…
6. Now my application waits on eventfd 21, but device interrupt signals 34
Any suggestion how to fix this?
Could we modify rte_intr_efd_enable so if eventfd already allocated(efds[i] is not 0) then don’t reallocate?
Hmm… seems 0 is a valid eventfd value https://man7.org/linux/man-pages/man2/eventfd.2.html
Maybe we could initialize it to invalid value (-1), and use -1 to decide if eventfd need to allocate or not?
Thank you.
Best regards
Yan Xiaoping
From: Yan, Xiaoping (NSB - CN/Hangzhou)
Sent: 2020年7月31日 18:15
To: 'tiwei.bie@intel.com' <tiwei.bie@intel.com>; dev@dpdk.org
Subject: interrupt mode issue for virtio device
Hi,
I have a dpdk application run in interrupt mode(like examples\l3fwd-power) for a virtio device
Network devices using DPDK-compatible driver
============================================
0000:00:04.0 'Virtio network device 1000' drv=vfio-pci unused=igb_uio
It works (application is waken up when packet come in) in some host infrastructure, but doesn’t work ((application is NOT waken up when packet come in)) in some other.
In the host where it doesn’t work, I found the interrupt increases in cat /proc/interrupts for this device.
It seems the fd in efds (value 34) mismatch the fds added to epfd (value 33) where my application is wating.
The other 2 ports (they are sriov VF device) works normally.
(gdb) print *(rte_eth_devices[0]->intr_handle)
$1 = {{vfio_dev_fd = 13, uio_cfg_fd = 13}, fd = 14, type = RTE_INTR_HANDLE_VFIO_MSIX, max_intr = 2, nb_efd = 1,
efd_counter_size = 0 '\000', efds = {34, 0 <repeats 31 times>}, elist = {{status = 1, fd = 21, epfd = 33, epdata = {
event = 2147483651, data = 0x0, cb_fun = 0x6c1b10 <eal_intr_proc_rxtx_intr>, cb_arg = 0x7a592f8}}, {status = 0, fd = 0,
epfd = 0, epdata = {event = 0, data = 0x0, cb_fun = 0x0, cb_arg = 0x0}} <repeats 31 times>}, intr_vec = 0x2ab525a0f80}
(gdb) print *(rte_eth_devices[1]->intr_handle)
$2 = {{vfio_dev_fd = 16, uio_cfg_fd = 16}, fd = 17, type = RTE_INTR_HANDLE_VFIO_MSIX, max_intr = 2, nb_efd = 1,
efd_counter_size = 0 '\000', efds = {22, 0 <repeats 31 times>}, elist = {{status = 1, fd = 22, epfd = 33, epdata = {
event = 2147483651, data = 0x100, cb_fun = 0x6c1b10 <eal_intr_proc_rxtx_intr>, cb_arg = 0x7a5c178}}, {status = 0, fd = 0,
epfd = 0, epdata = {event = 0, data = 0x0, cb_fun = 0x0, cb_arg = 0x0}} <repeats 31 times>}, intr_vec = 0x2ab525a09c0}
(gdb) print *(rte_eth_devices[2]->intr_handle)
$3 = {{vfio_dev_fd = 19, uio_cfg_fd = 19}, fd = 20, type = RTE_INTR_HANDLE_VFIO_MSIX, max_intr = 2, nb_efd = 1,
efd_counter_size = 0 '\000', efds = {23, 0 <repeats 31 times>}, elist = {{status = 1, fd = 23, epfd = 33, epdata = {
event = 2147483651, data = 0x200, cb_fun = 0x6c1b10 <eal_intr_proc_rxtx_intr>, cb_arg = 0x7a59ab8}}, {status = 0, fd = 0,
epfd = 0, epdata = {event = 0, data = 0x0, cb_fun = 0x0, cb_arg = 0x0}} <repeats 31 times>}, intr_vec = 0x2ab525a0400}
so although eventfd-count for 34 is increasing, my application is not waken up
# grep -r eventfd-count /proc/1910/fdinfo/
…
/proc/1910/fdinfo/28:eventfd-count: 0
/proc/1910/fdinfo/30:eventfd-count: 114b5da
/proc/1910/fdinfo/31:eventfd-count: 0
/proc/1910/fdinfo/34:eventfd-count: 2054
The epoll fd 33 seems doesn’t include eventfd 34
# cat /proc/1910/fdinfo/33
pos: 0
flags: 02
mnt_id: 11
tfd: 21 events: 8000001b data: 7a59390 pos:0 ino:2514 sdev:b
tfd: 22 events: 8000001b data: 7a5c210 pos:0 ino:2514 sdev:b
tfd: 23 events: 8000001b data: 7a59b50 pos:0 ino:2514 sdev:b
tfd: 31 events: 8000001b data: 7fffffffe230 pos:0 ino:2514 sdev:b
My application register event like this(like examples\l3fwd-power):
rte_eth_dev_rx_intr_ctl_q(portid, queueid,RTE_EPOLL_PER_THREAD, RTE_INTR_EVENT_ADD, (void *)((uintptr_t)data));
I doubt the efds has changed after the register, but can’t find how this could happen…
Any idea please?
DPDK version in use: 18.05
I saw 1 commit in 19.05 might be relevant.(in my case, there is secondary dpdk process, my application is the primary process)
Could you please confirm?
commit 1c8489da561be16ac73c6dab01db816af249713f
Author: Tiwei Bie <tiwei.bie@intel.com<mailto:tiwei.bie@intel.com>>
Date: Mon Mar 25 12:12:15 2019 +0800
net/virtio-user: fix multi-process support
This patch fixes the multi-process support for virtio-user.
Currently virtio-user just provides some limited secondary
process supports. Only some basic operations can be done in
secondary process on virtio-user port, e.g. getting port stats.
Actions which will trigger the communication with vhost backend
can't be done in secondary process for now, as the fds are
not synced between processes. The processing of server mode
devargs is also moved into virtio_user_dev_init().
Fixes: cdb068f031c6 ("bus/vdev: scan by multi-process channel")
Fixes: ee27edbe0c10 ("drivers/net: share vdev data to secondary process")
Cc: stable@dpdk.org<mailto:stable@dpdk.org>
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com<mailto:tiwei.bie@intel.com>>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com<mailto:maxime.coquelin@redhat.com>>
Thank you.
Best regards
Yan Xiaoping
prev parent reply other threads:[~2020-08-06 10:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 10:15 Yan, Xiaoping (NSB - CN/Hangzhou)
2020-08-02 2:47 ` Yan, Xiaoping (NSB - CN/Hangzhou) [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=c561b344d05c4f55b4fafd9be45247f3@nokia-sbell.com \
--to=xiaoping.yan@nokia-sbell.com \
--cc=dev@dpdk.org \
--cc=tiwei.bie@intel.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).