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 9C11D45CED; Tue, 12 Nov 2024 06:21:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 60D88402C3; Tue, 12 Nov 2024 06:21:20 +0100 (CET) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by mails.dpdk.org (Postfix) with ESMTP id AAA67400D6 for ; Tue, 12 Nov 2024 06:21:19 +0100 (CET) Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-20cf3e36a76so53833005ad.0 for ; Mon, 11 Nov 2024 21:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1731388879; x=1731993679; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=yq0+shosDYQm1BE/RwOl5IzhMGX1k1A0Vcs3J0Kr2MY=; b=y5awUOcvG1lDyCC3jCmX7r8lbeNQhYuQdCbmmsV1FrrWT33qjBJLN/8/aJqwms5QCl FYNMjNBUCqL48+a9AdHihseO4tbZGWcA+DmGvc6OVu8MW7Xalz/gMfM9l9a+utbmFl9U Bl9dAm9EK5Jo2Vsm7doqpMIStzF3OolUorarxeAkj5PqEoP22Z7t/qD6ahSosKcRzkzc dskacwL3bw6xmsT+g6v0JEDrFLqVf6bXag9JOdrZkIyjT27th+j8R2Ar7PJqNFQqj07F o8mYBrmZp5/5TIENYbn4qql7XA/bfXKn1S/FlJfemFAVNJc1+VrD5qctNRu6WXDgLmRa ZdhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731388879; x=1731993679; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yq0+shosDYQm1BE/RwOl5IzhMGX1k1A0Vcs3J0Kr2MY=; b=CoLbDlTE72phvElk9IQNWVev9+z10pE5hQG9fTNv8iG/Z8JXcrWc9u1dryOxKICETO Lab8AulN+3+Ipv/Kdz5KjnxCKIGmNvvwLlFMw9IJUCxzlzGGDJEU85TG9R5xjrhZEol+ qkJewD554L4BatsG/S65v3v0kKJbDsiektXmwUnsQRVVBDI7dF3/0wdc4p24v+XM5VaK mecQvDc67ckDXYfqAdoX+MO98K1Zd61qk4ax6yDbOpn4U4gwRM4uGzCHa25meq1yxtKi KJ9Ge0tEzPFbbbx5y2B/kp6q3tAdmikagc5Qyk3S2LNBE0b67cWx/3P7iiNxr8MWx00i 1JCg== X-Gm-Message-State: AOJu0YyLs8VhghXikUJ3u3MVGd9/AX8se6kQh6MKZx17N0aaI/Ic043l UjUAm1U5xmty/2oHO7G4HTuAIBwumEfpg9qbXTWXMUTzTReM4rMZpM62CT3LhfA= X-Google-Smtp-Source: AGHT+IH93uiJp9bD2cb7nbHpxnyOeceXYYuf3BKvp2fS/Vi9JOl/9zEOuSEp4QbSn8xwlD4ihZxbUQ== X-Received: by 2002:a17:903:11d0:b0:211:8404:a957 with SMTP id d9443c01a7336-2118404a967mr201201525ad.41.1731388878235; Mon, 11 Nov 2024 21:21:18 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21177e5810csm85185715ad.179.2024.11.11.21.21.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2024 21:21:17 -0800 (PST) Date: Mon, 11 Nov 2024 21:21:16 -0800 From: Stephen Hemminger To: Maxime Coquelin Cc: dev@dpdk.org Subject: Re: RFC - Tap io_uring PMD Message-ID: <20241111212116.28090881@hermes.local> In-Reply-To: References: <20241030145644.0b97f23c@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 6 Nov 2024 08:46:55 +0100 Maxime Coquelin wrote: > Hi Stephen, > > On 10/30/24 22:56, Stephen Hemminger wrote: > > The current tap device is slow both due to architectural choices and the > > overhead of Linux system calls. I am exploring a how to fix that but some > > of the choices require some tradeoffs. Which leads to some open questions: > > > > 1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header > > only L3. Does anyone actually use this? It is different than what every other > > PMD expects. > > > > 2. The fastest way to use kernel TAP device would be to use io_uring. > > But this was added in 5.1 kernel (2019). Rather than having conditional or > > dual mode in DPDK tap device, perhaps there should just be a new PMD tap_uring? > > > > 3. Current TAP device provides hooks for several rte_flow types by playing > > games with kernel qdisc. Does anyone really use this? Propose just not doing > > this in new tap_uring. > > > > 4. What other features of TAP device beyond basic send/receive make sense? > > It looks like new device could support better statistics. > > > > 5. What about Rx interrupt support? > > > > Probably the hardest part of using io_uring is figuring out how to collect > > completions. The simplest way would be to handle all completions rx and tx > > in the rx_burst function. > > > > Why not just use Virtio-user PMD with Vhost-kernel backend [0]? > Are there any missing features that io_uring can address? > > Regards, > Maxime > > [0]: http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html > Yes, I looked at that but: - virtio user ends up with a busy kernel thread which is not acceptable in SOC environment where all resources are locked down. In the SOC I was working on DPDK was limited to 4 polling isolated CPU's and 1 sleeping main thread. The rest of the CPU resources were hard constrained by cgroups. The virtio user thread was a problem. - virtio user device is not persistent. If DPDK is being used a dataplane, need to be able to quickly restart and not disturb applications and routing in the kernel while the tap device is unavailable. I.e having device present but in no carrier state is better than having to teach applications about hot plug or play around with multiple addresses on loopback device (which is what Cisco routers do).