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 4639642526 for ; Wed, 6 Sep 2023 10:43:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FE0A402BD; Wed, 6 Sep 2023 10:43:35 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 403E2402BC for ; Wed, 6 Sep 2023 10:43:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693989813; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qVICU0kxux/5SrGGU9a6E7gc10IKp8t0Y8iQHt/oJc0=; b=D23SFXHvql709lC604nIr5rupj8VBwmvSGauTef6d1nYPlCrbL/H7vdJEFsTlN/kd5S8oB aR7Hx1xrAYNYMB41ib2BP55PQuCEQJE47Y5/1JEHNXrI+TXdcyPeFC1I9K8IJQ6WxOO2Gh qCbhHcdmxxbT53DeNfRGhUu+p/OL72k= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-260-hnVPc5gRPdC0CkDtFTBKzg-1; Wed, 06 Sep 2023 04:43:30 -0400 X-MC-Unique: hnVPc5gRPdC0CkDtFTBKzg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 571CD3C108C5; Wed, 6 Sep 2023 08:43:30 +0000 (UTC) Received: from [10.39.208.8] (unknown [10.39.208.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 09F9921EE565; Wed, 6 Sep 2023 08:43:28 +0000 (UTC) Message-ID: <97206ec2-840a-36c3-4128-72c580f92621@redhat.com> Date: Wed, 6 Sep 2023 10:43:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: =?UTF-8?B?Tmljb2xzb24gS2VuICjjg4vjgrPjg6vjgr3jg7Mg44Kx44OzKQ==?= , David Marchand Cc: "users@dpdk.org" , "Xia, Chenbo" References: From: Maxime Coquelin Subject: Re: Implementing a simple TAP PMD to dpdk-vhost structure In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/6/23 10:28, Nicolson Ken (ニコルソン ケン) wrote: > Hi Maxime, > >> Maybe you could use testpmd application instead, with net_tap PMD and a net_pcap PMD? > > I have an existing solution that uses the TAP PMD which I then add to a standard kernel bridge that allows me to have two-way communication with the Guest VM, but I suspect the performance would be better if we were to use a DPDK virtio-based solution; otherwise I could just drop DPDK all together and use tcpreplay, etc to directly access the bridge. Ha yes, I misread the initial thread. You should indeed use testpmd with Vhost PMD and net_pcap, I'm pretty sure I've done that in the past. > > [Also net_pcap only outputs to kernel interface (or to a file or null) as it uses libpcap APIs for Tx] > >> An alternative to net_tap could be to use Virtio-user PMD with Vhost- kernel backend. > > That uses KNI, which the documentation says is deprecated, and I'm not sure I want to start mucking about with kernel drivers. Virtio-user PMD with kernel backend is an alternative solution to KNI, no out-of-tree driver needed. But that should not be the way to go for your usecase. Maxime > Thanks, > Ken > > -----Original Message----- > From: Maxime Coquelin > Sent: Wednesday, September 6, 2023 4:16 PM > To: David Marchand ; Nicolson Ken (ニコルソン ケン) > Cc: users@dpdk.org; Xia, Chenbo > Subject: Re: Implementing a simple TAP PMD to dpdk-vhost structure > > > > On 9/6/23 08:07, David Marchand wrote: >> Hello Ken, >> >> On Wed, Sep 6, 2023 at 3:56 AM Nicolson Ken (ニコルソン ケン) >> wrote: >>> >>> Hi all, >>> >>> Using dpdk 22.11.2 on Ubuntu 22.04 >>> >>> I have a really simple use case, but I cannot find how to implement it. I've set up QEMU with all the required virtio support, so I just need to configure my Host OS-side. I want to send data from a PCAP file via tcpreplay from the Host to the Guest, so I use this command line: >>> >>> $ sudo /home/integ/dpdk-stable-22.11.2/build/examples/dpdk-vhost -l >>> 0-3 -n 4 --socket-mem 1024 --vdev 'net_tap0' -- --socket-file >>> /tmp/sock0 --client -p 1 >>> >>> However, this fails with: >>> >>> EAL: Detected CPU lcores: 20 >>> EAL: Detected NUMA nodes: 1 >>> EAL: Detected static linkage of DPDK >>> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket >>> EAL: Selected IOVA mode 'PA' >>> VHOST_PORT: Failed to get VMDq info. >>> EAL: Error - exiting with code: 1 >>> Cause: Cannot initialize network ports >>> >>> The offending code is from examples/vhost/main.c: >>> >>> if (dev_info.max_vmdq_pools == 0) { >>> RTE_LOG(ERR, VHOST_PORT, "Failed to get VMDq info.\n"); >>> return -1; >>> } >>> >>> This is because the TAP PMD doesn't support VMDq pools. >>> >>> Is there an easy way to get this to work? >> >> This sounds strange to require VMDq support... >> Copying Maxime and Chenbo who probably know better about this example code. >> >> Alternatively, did you consider using testpmd with the vhost pmd instead ? >> >> > > Maybe you could use testpmd application instead, with net_tap PMD and a net_pcap PMD? > > An alternative to net_tap could be to use Virtio-user PMD with Vhost- kernel backend. > > Maxime >