From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B198B48879 for ; Wed, 1 Oct 2025 04:52:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5E22140265; Wed, 1 Oct 2025 04:52:09 +0200 (CEST) Received: from ns.mahan.org (unknown [23.24.207.145]) by mails.dpdk.org (Postfix) with ESMTP id 25321400EF for ; Wed, 1 Oct 2025 04:52:06 +0200 (CEST) Received: from [192.168.1.51] (crowTrobot [23.24.207.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ns.mahan.org (Postfix) with ESMTPSA id 400CD2BD18; Tue, 30 Sep 2025 19:52:10 -0700 (PDT) Message-ID: <4ff2b4d4-c6b9-4168-b1e0-b02aa4018316@mahan.org> Date: Tue, 30 Sep 2025 19:52:03 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Use of the 'virtio-user' exception path interface To: Stephen Hemminger Cc: users@dpdk.org References: <20250928092707.3625a385@hermes.local> Content-Language: en-US From: Patrick Mahan In-Reply-To: <20250928092707.3625a385@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On 9/28/25 9:27 AM, Stephen Hemminger wrote: > On Sat, 27 Sep 2025 18:41:58 -0700 > Patrick Mahan 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: 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: 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. Thanks for the suggestion, but as far as I can tell, our udev rules only exist for USB devices, there are not any for virtual interfaces. Continuing to investigate... Thanks, Patrick