From: Stephen Hemminger <stephen@networkplumber.org>
To: Patrick Mahan <mahan@mahan.org>
Cc: users@dpdk.org
Subject: Re: Use of the 'virtio-user' exception path interface
Date: Sun, 28 Sep 2025 09:27:07 -0700 [thread overview]
Message-ID: <20250928092707.3625a385@hermes.local> (raw)
In-Reply-To: <b9580e26-29f9-47e8-bb44-8b2836b7032e@mahan.org>
On Sat, 27 Sep 2025 18:41:58 -0700
Patrick Mahan <mahan@mahan.org> wrote:
> This is on yocto-linux 4.19.87 on X86_64. DPDK (stable) 18.11.11
>
> I am working on a project where I am trying to make use of the 'virtio-user'
> exception path and it (sort of) seems to be working. The issue I am trying to
> understand is the following:
>
> Background -
>
> Per the how-to documentation
> (https://doc.dpdk.org/guides-25.07/howto/virtio_user_as_exception_path.html), I
> have called rte_eal_init() passing in the PCI address of my physical interfaces.
> I am also creating a couple of these "exception" interfaces with the following code -
>
> char portname[32], portargs[256];
> char macaddr[6] = { 0x00, 0x0c, 0x1b, 0x29, 0x29, 0x71 };
> uint16_t portid;
>
> /**
> * Create the first 'iflan0'
> */
> snprintf(portargs, 256,
> "path=/dev/vhost-net,queues=2,queue_size=1024,iface=iflan0,mac=%02x:%02x:%02x:%02x:%02x:%02x",
> macaddr[0], macaddr[1], macaddr[2], macaddr[3], macaddr[4], macaddr[5]);
>
> /**
> * Call the hotplug layer
> */
> if (rte_eal_hotplug_add("vdev", "virt-user0", portargs) < 0) {
> fprintf(stderr, "[DPDK::hotplug] failed to create iflan0 (virtio-user0)\n");
> return -1;
> }
>
> /**
> * Create the second 'ifwan0'
> */
> macaddr[5]++;
> snprintf(portargs, 256,
> "path=/dev/vhost-net,queues=2,queue_size=1024,iface=ifwan0,mac=%02x:%02x:%02x:%02x:%02x:%02x",
> macaddr[0], macaddr[1], macaddr[2], macaddr[3], macaddr[4], macaddr[5]);
>
> /**
> * Call the hotplug layer
> */
> if (rte_eal_hotplug_add("vdev", "virt-user1", portargs) < 0) {
> fprintf(stderr, "[DPDK::hotplug] failed to create iflan0 (virtio-user0)\n");
> return -1;
> }
>
> ...
>
> RTE_ETH_FOREACH_DEV(portid) {
> if (port_init(portid, bufPool, NRXQUEUES, NTXQUEUES) < 0) {
> fprintf(stderr, "[DPDK::port_init] failed to init DPDK port %u",
> portid);
> return -1;
> }
> }
>
> ...
>
> /* Retrieve the ifindex of iflan0 and ifwan0 */
> unsigned int iflan0_index = if_nametoindex("iflan0");
> unsigned int ifwan0_index = if_nametoindex("ifwan0");
>
> fprintf(stdout, "[DPDK] Exception interface 'iflan0': %u", iflan0_index);
> fprintf(stdout, "[DPDK] Exception interface 'ifwan0': %u", ifwan0_index);
>
> ... /* onto the packet processing loops */
>
> The interfaces are instantiated and those two logs messages are seen -
>
> . . .
> [DPDK] Exception interface 'iflan0': 58
> [DPDK] Exception interface 'ifwan0': 59
> . . .
>
> However, when I check the list of kernel interfaces using 'ip link show', I find:
>
> pmahan-dpdk-v1: # ip link show
> . . .
> 66: iflan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> group default qlen 1000
> link/ether 00:0c:1b:29:29:71 brd ff:ff:ff:ff:ff:ff
> 67: ifwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> group default qlen 1000
> link/ether 00:0c:1b:29:29:72 brd ff:ff:ff:ff:ff:ff
>
> So, some point after I created and started these ports and obtain the original
> ifindexes, they were deleted and re-created. I have some clue from the IKE
> kernel log messages:
> ...
> Sep 27 23:30:22 2025 pmahan-dpdk-v1 IKE: 11[KNL] interface iflan0 activated
> Sep 27 23:30:22 2025 pmahan-dpdk-v1 IKE: 09[KNL] interface ifwan0 activated
> ...
> Sep 27 23:30:22 2025 pmahan-dpdk-v1 IKE: 09[KNL] interface iflan0 deactivated
> Sep 27 23:30:22 2025 pmahan-dpdk-v1 IKE: 13[KNL] interface iflan0 deleted
> Sep 27 23:30:22 2025 pmahan-dpdk-v1 IKE: 12[KNL] interface ifwan0 deactivated
> Sep 27 23:30:22 2025 pmahan-dpdk-v1 IKE: 05[KNL] interface ifwan0 deleted
>
> I never see another IKE log about those interfaces being activated again
> (possibly because they show as DOWN).
>
> Short of crawling through the guts of the virtio-user support in vdev, I thought
> I would start asking questions here.
>
> Also, is there any specific logging I can enabled to see if I can understand why
> this is happening?
>
> Thanks for any help,
>
> Patrick
>
It maybe that your systems networking code (udev) in user space is reacting
to the new interface.
next prev parent reply other threads:[~2025-09-28 16:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 1:41 Patrick Mahan
2025-09-28 16:27 ` Stephen Hemminger [this message]
2025-10-01 2:52 ` Patrick Mahan
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=20250928092707.3625a385@hermes.local \
--to=stephen@networkplumber.org \
--cc=mahan@mahan.org \
--cc=users@dpdk.org \
/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).