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 C5F1643A02 for ; Mon, 29 Jan 2024 18:21:51 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 602524029A; Mon, 29 Jan 2024 18:21:51 +0100 (CET) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by mails.dpdk.org (Postfix) with ESMTP id 010A14026F for ; Mon, 29 Jan 2024 18:21:49 +0100 (CET) Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-5d7005ea1d0so1876733a12.1 for ; Mon, 29 Jan 2024 09:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1706548909; x=1707153709; 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=T8N/UlYfgSFh1G6y3BHWoYBwz/BBCSPMnFMJJnLtWN0=; b=sj2IDZonEvR4EQv5p5sTXhoJawGLOlyjEUAXJ/bhGJ7sau7Q9LezrppA0GNSX6cHf1 9qewfmlgXEGdBnHPRpfvW0I/VuRWj0jy7Au7Fn+Hk6Rb8cIcCglWcKUETgW1OKe0/3HD k7AH4kjV/ugsMJyjnxnpWayvlgXY8UW8GOvBJTBPBQfxEOV4P55nDKa+OSZTZFYOLiw7 8NsZ+WbyCxII5er/laSH2rT09Y/xQtajqA1Fw4nPmLcttKlWGPlS6bS0V07rtAeMKrh2 xv6xhHkiuTXHDLTte1eZv2kBj5mBZw3SgClW0hgC9tJSzv2s2EPx6HNCTgg4ACp9V9vk NrsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706548909; x=1707153709; 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=T8N/UlYfgSFh1G6y3BHWoYBwz/BBCSPMnFMJJnLtWN0=; b=vpWn5Izmlk0ssHClWoAAKPk6cIDb/ixwbyehpfVAk7x4QK0Y3QIAU9rAkG0jHGiwtQ 6LfCUBZyCyRIERIAFv+9NNQrWtSRylKNg5PgDTc3OzmTjTuaF9e4+2kBwatQnHzOgnsT 2eIAewMBM3XxOUSOnXB5OgmSmyo+E07r7Z4tABt+mbDoozZw5GgxMJVxbt+je5Hr3C0P cv0rT1UBUawXpXlkIzwkYGUUyPxrKzY+4hnP+nTWfOjMgsIxMo4N0YMwNWG9jBBCpWkb xNGtJzWd7LHLIH1vquQzP3XSjXOoJxB1lHAte4VBjRGhMT5QSSXFWj9X/+oOlgcwMx4W yeMA== X-Gm-Message-State: AOJu0YwwbwpIOOusCUFlc+Lzyz7lG5L5kayGmKyAwRJSDwiePXHbLuiJ Yrfr2uAg2AkrBBhQoh2NrZT3GKZBE9yx+wFY1/x01PCNwHHRs5etEMtKzmQ94XScCIUO9j6XtWY cLc0= X-Google-Smtp-Source: AGHT+IEzjBnKqXhNTpWbmpJNcnCH3FYMSuMVk85AsNezBJBfNfbZ7Ph3AtQ6LhF+gBGEctu4p5DR/Q== X-Received: by 2002:a05:6a20:ce9e:b0:19c:621d:7f73 with SMTP id if30-20020a056a20ce9e00b0019c621d7f73mr5433546pzb.24.1706548908913; Mon, 29 Jan 2024 09:21:48 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id q21-20020a62e115000000b006ddd22b79f6sm6116335pfh.120.2024.01.29.09.21.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 09:21:48 -0800 (PST) Date: Mon, 29 Jan 2024 09:21:47 -0800 From: Stephen Hemminger To: Pavel Vazharov Cc: users Subject: Re: Split traffic between the Linux stack and DPDK application Message-ID: <20240129092147.231a1826@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Mon, 29 Jan 2024 18:09:28 +0200 Pavel Vazharov wrote: > Hi there, > > A DPDK can run on top of XDP sockets and use custom XDP program to split > the traffic between the Linux stack and the DPDK application. This way > still allows zero copy between the kernel and the DPDK application. > Is there another zero-copy way to achieve redirecting some part of the > traffic to the Linux kernel and another to a DPDK application? > For example, AFAIK I can run the DPDK application and redirect packets from > inside to the Linux stack via the DPDK KNI functionality but it'll be much > slower because it'll require packets copying and context switch (if I'm not > mistaken). > > Regards, > Pavel. There is no generic solution. It is possible with some hardware drivers like Mlx. Intel was working on bifurication as well but seems to have abandoned it. KNI is no longer part of DPDK, and it did a copy (hidden in kernel). The problem with zero copy from kernel point of view is how to deal with packet lifetime.