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 29DE942BB4 for ; Sat, 27 May 2023 12:04:23 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8BFF241141; Sat, 27 May 2023 12:04:22 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 02C274021D for ; Sat, 27 May 2023 12:04:21 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1b0314f057cso48755ad.1 for ; Sat, 27 May 2023 03:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685181861; x=1687773861; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DBXYBdsm1FwimH3R7XKsgjBA/O3+5zQssIY2TiDgDOQ=; b=Kg8breqmruZl/CUoJxFZeauvX5preIjBwtMh0/9eEYU+iv/gl70eJBDrHM0ctty1bW HfACbG+JOnE/CZ4TZ4JD9BCtfpzetZTIx7V8N6IC4Krks+M1zBkHRUwIG+U6KQ/112YG vUy2SR3Sdey0wajAdx9MnOQh4CmiodRMSrO02t3qBw0yDvVk78rQKYvx8bnEiYLkJkO7 hxWhMd5hIivmDoVZv4Q/bnvHsEJ9NlE2YLGKIqurUkJvAxUxPda2ju/ZDJvyA2WUgD4R 6M+EHAGgHdzl5E4SV1I4rDTdGXboga1NYz9sGq+T31DVEe4oFYzCCBDhvue7XyWdH2Z7 KgWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685181861; x=1687773861; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DBXYBdsm1FwimH3R7XKsgjBA/O3+5zQssIY2TiDgDOQ=; b=ZaLF50IpO3xZ+HdYntLQuHb1zQlI5vm+eicILnenrQTPYsovhB9xmbvcEDsByf4uy5 P0i9WaUvnWMdmyHb30uRB20+5Izdtm7mWZzB5+X6/rUTeKpLPHfUrJsIDzZQ2OZ/FBIl 1cAdcJG8A8qAB9v4oU8CQRh7XIZrCppEYETBUcWShL/V4InK9ipIaT8y/lAXHr97BF4/ GUDP1qnepZlfm3ERWRpc1SBOkhgXefaVJbxRdw/rrXuyndBBqYes+85Eq8NV1dUkvnbY 7HeBJnD3qCqQ7QgVUFLkiw16RK31/6IhkaUD01tV2eR9KCUbar6kZgcQ99Ho66m8UsKx 6Lvg== X-Gm-Message-State: AC+VfDwARj95bQuxh2W0+/4FSjqxzfHlh2wgyhoN37+t50L3EuniwkVO LwXlnNhzeuJ/ElowGA/9MSo1arl7+mla6NZF5tbg1lxXoK1OQQ== X-Google-Smtp-Source: ACHHUZ4WJRJZ1v+GR+YeLT+zujEWuXDV0CjvtxiDjtmu9bxfFMo9whmBs2kMFu8yBKmXx2e6qH2S5pzd4lAkg79MB9E= X-Received: by 2002:a17:903:22cd:b0:1aa:cf25:41d0 with SMTP id y13-20020a17090322cd00b001aacf2541d0mr6830085plg.33.1685181860698; Sat, 27 May 2023 03:04:20 -0700 (PDT) MIME-Version: 1.0 References: <20230523092322.25757e84@hermes.local> In-Reply-To: <20230523092322.25757e84@hermes.local> From: Igor de Paula Date: Sat, 27 May 2023 11:04:10 +0100 Message-ID: Subject: Re: help with virtio_port Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thanks! It's weird because on the KNI version, I am listening on the port and waiting for a link message. If I run tcpdump there is no packet coming on that port but the rte_handle_kni_request doe's deal with it. When I try to listen on the port, without KNI, when I am using virtio_user I do get a packet when I use tcpdump. I guess when KNI initialized it takes the traffic associated with the functions it supports. Can someone confirm that this is actually the case? Many thanks for the help so far On Tue, May 23, 2023 at 5:23=E2=80=AFPM Stephen Hemminger wrote: > > On Tue, 23 May 2023 16:46:24 +0100 > Igor de Paula wrote: > > > Hi, > > I am running the DPDK version: 21.08.0 and Ubuntu 20.04.3 LTS. > > I have an application that uses KNI to interface with the kernel. > > I want to replace it with virtio_user ports as KNI will be deprecated i= n > > the future. > > Most of the functionality I am able to replace but there is one thing I= am > > struggling with. > > In KNI we can add functions that will be called in case the network sta= ck > > makes a request. The following code shows this: > > struct rte_kni *kni; > > struct rte_kni_conf conf; > > struct rte_kni_ops ops; > > struct rte_eth_dev_info dev_info; > > int ret; > > /* Clear conf at first */ > > memset(&conf, 0, sizeof(conf)); > > conf.core_id =3D 0; > > memset(&ops, 0, sizeof(ops)); > > ops.port_id =3D ppo->id; > > ops.config_promiscusity =3D ippe_ppo_set_kni_promiscuous_mode; > > ops.change_mtu =3D ippe_ppo_set_kni_mtu; > > ops.config_network_if =3D ippe_ppo_set_kni_interface; > > ops.config_mac_address =3D ippe_ppo_set_kni_mac_address; > > kni =3D rte_kni_alloc(pktmbuf_pool[0], &conf, &ops); > > > > > > And there is a handle_request function supplied by KNI that calls these > > functions when need be, > > I haven't found any documentation on how to replace this functionality.= I > > am no expert in how to set up and interact with the kernel stack, Some = help > > on how to achieve this would be appreciated. > > If you want to handle changes to kernel network device, then you > will have to build a netlink listener that monitors these changes.