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 5112745C89; Wed, 6 Nov 2024 01:53:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D598E42D3F; Wed, 6 Nov 2024 01:53:30 +0100 (CET) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by mails.dpdk.org (Postfix) with ESMTP id 457BB4027E for ; Wed, 6 Nov 2024 01:53:28 +0100 (CET) Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-7ed9c16f687so4254325a12.0 for ; Tue, 05 Nov 2024 16:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730854407; x=1731459207; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4YKz3Da41JHdeM5l5kz4A8jyHM77t/E4hgdKaEQ+tpE=; b=URSiMZ9eFMbJe13Ke4dnoGFBkPy/K8dtAM2c+RgPhfmSUgkeArVfsafOpgEWjtodDb gZ1k1aT7Vi7y+HMyTIruguIS2oPiUcOE2mJn0ak4xG9c3c9gnqR54s4Tm2vUB5FXK9/W rJ0OlmBT9JJPU3rBrO48peZrupXXotpLrSUYlju/CVRUzL1cIiEGitGyZnwMPBEgUjnt 26WTmb1KY2rT9W5Z000DfzhdOzbNB21OXAKGLdUMlDIpOnN4U7VtT76hKFFJDIPERS/B QItIINsPQRTwtnI+IzQUECQI4jd5/tUjXJgvlSYLa71Mu6DlJbNzsGGrlOuTNgTOI6ho UH5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730854407; x=1731459207; h=content-transfer-encoding:cc:to: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=4YKz3Da41JHdeM5l5kz4A8jyHM77t/E4hgdKaEQ+tpE=; b=TurEkvY0XV+FmCas6NBGIuvB5m1sj30iNPVN8Aadt4BeNFDGLlv8VvOkFfMFKqgcx+ lrTbi6d7a73IMf1Ri7PWOHjmJYv1cineFroKNx6gK3trhtKAGe6L0RAuEZOpuHduTlXj tSLuTc1fhrWO0LMZ2ahqcsgmIW2f0SfSJEbESXkujP3LWncIPxAdDqiHTp3WYJv6pxLq Hqvqf3D7Y68O0RbxroExl4WdZ7teU1vD7ARkjVaJxCt9LfnrJ1Mk3envNFlqj7QZi/VW 3Ahm2L10NI6oYovCymI04cOAdVx/VHbODuEvuXm+7IJCOBPpDf44LPOu39ryB+8v4Ea9 Embg== X-Gm-Message-State: AOJu0YxRWmKqOg4aV560DGq1SXmsr/XpFZrv6T/Gk6Xr0XxUgJMmqOVD xE36majWmPS/MZfM4wyNGuU+3sAMZ1Qk3CIqSOcrCgO0LPilqCeM5+8/1Pc2elD3KClZ2BIaO6x 8b1MktOjD/h6Tjo+L6SayAHdF0ihDMKt7 X-Google-Smtp-Source: AGHT+IEpBpOF/LlUA4AMUMgRH7WiC7Jupc2mGMvtlelEbDIQTlC59M4Wnb2X6eLBsdY+m2XeJOuqY8clMyl1NwvfSqo= X-Received: by 2002:a05:6a21:7887:b0:1db:e1b0:b679 with SMTP id adf61e73a8af0-1dbe1b0b8bamr10659404637.18.1730854407268; Tue, 05 Nov 2024 16:53:27 -0800 (PST) MIME-Version: 1.0 References: <20241030145644.0b97f23c@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F858@smartserver.smartshare.dk> <20241031173450.26cdb54c@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F86A@smartserver.smartshare.dk> <20241105105839.36c85e8f@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F885@smartserver.smartshare.dk> <20241105152556.2e5b8f91@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F886@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F886@smartserver.smartshare.dk> From: Igor Gutorov Date: Wed, 6 Nov 2024 03:52:51 +0300 Message-ID: Subject: Re: RFC - Tap io_uring PMD To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Nov 6, 2024 at 2:54=E2=80=AFAM Morten Br=C3=B8rup wrote: > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Wednesday, 6 November 2024 00.26 > > > > On Wed, 6 Nov 2024 00:22:19 +0100 > > Morten Br=C3=B8rup wrote: > > > > > From what I understand, the TAP io_uring PMD only supports one RX > > queue per port and one TX queue per port (i.e. per TAP interface). We > > can take advantage of this: > > > > > > No kernel tap support multi queue and we need to use that. > > Maybe I got it wrong then... I thought you said fanout (of kernel->TAP pa= ckets) would affect all fds associated with the TAP interface. > How can the application then use multiple queues? > > Another thing is: > For which purposes do applications need multi queue support for TAP, cons= idering the interface is for management traffic only? I've previously used net_pcap as well as net_af_packet PMDs for debugging/testing and even benchmarking purposes. I'd set up a software interface, then feed test traffic via `tcpreplay`. Some of the limitations I've encountered are: - net_af_packet does not report received/missed packet counters - net_pcap does not have multi queue support (AFAIK) As an example, non symmetric RSS configurations may cause 2-way TCP packets to be steered to different queues. If your application is a worker-per-queue application with no shared state, you might want to have these packets to be steered to the same queue instead. Without multi queue, you can't easily test against scenarios like that. Though, as you've said, if TAP is for management only, perhaps I was trying to use the wrong tool for the wrong job. In the end, I ended up getting a real two port NIC (feeding traffic from one port to the other) because software PMDs are not similar enough to the actual hardware. -- Igor