From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4BC7EA04E1; Tue, 22 Sep 2020 09:41:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E52F61C210; Tue, 22 Sep 2020 09:41:05 +0200 (CEST) Received: from wnew1-smtp.messagingengine.com (wnew1-smtp.messagingengine.com [64.147.123.26]) by dpdk.org (Postfix) with ESMTP id B39BD1C1E9 for ; Tue, 22 Sep 2020 09:41:04 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 77E4BC7B; Tue, 22 Sep 2020 03:41:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 22 Sep 2020 03:41:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= 2S0pRi+Q8fpOUkZywWGNZMTC2jPnVFEnDq3RYUP2QYg=; b=GS6ugnJ1vStDUyxF TyCkloWiAxnvVF/yA1TjQwUnvmegt9DvKtt7LmhIR8BueT4ozpBErO/5/MVRT4BA J5SX9e8WRQ1mB3duw+gH0V8FXLBWHcGNuuvNhccMZqnvPytppN1lkG0MZutZxU/L 7wQTNCsue5pQfhymyJiZlfwypQ0SGyjMAjk7OBTPqrY/W2R5buWeUwzDeB+fupSJ ZQbyH2SGb0pKfed5nXl0iKjTgj9WGVm6lGwK41BJxx8JWoEd0QGqfrf5PK8J6gal FFHiEN/uMqHaX41rMPOl7onggfCj2+/jSeREtyI5vOYPwwqFgdvtokRqSM73OftD sAcPeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=2S0pRi+Q8fpOUkZywWGNZMTC2jPnVFEnDq3RYUP2Q Yg=; b=U6U4GVEdwgqDN9nDOuOlb5hHlG40e9Pma7tWHIwlI2EhtmFHaby1LfTpT 1JgrJJ5pE4Xms0gykIWPc74QgvtE00ZZd+Hqi5WH/YA5U1Ndl2L4Wk9eOXS8ErhN GXvDKhiNzTLeSgp/CHXaqYv2VVOwECVfYB9i5FUwRbFlOtiSiUg2vdFI/o0E76+V F8GIOhtR/uqwEaa54Q1yHnVJdDl+tMPJAASucQqkvWqeTbX9KM5e/EljdsmNxcaU yE9EjohaLxQmdWw0ftMbrHcsSi87y36mD9LPBTnNlZB4ZjWOnde/1YhxekuMhRBc 8V7FDxD6EMP9QH4eb6x6m0qIsEGsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B3135328005A; Tue, 22 Sep 2020 03:40:59 -0400 (EDT) From: Thomas Monjalon To: Patrick Fu Cc: dev@dpdk.org, ferruh.yigit@intel.com, maxime.coquelin@redhat.com, bruce.richardson@intel.com, mm6021@att.com, zhihong.wang@intel.com, liang-min.wang@intel.com, konstantin.ananyev@intel.com, timothy.miskell@intel.com, cunming.liang@intel.com, Jiawei Wang , Ori Kam , jerinj@marvell.com, cristian.dumitrescu@intel.com, arybchenko@solarflare.com Date: Tue, 22 Sep 2020 09:40:58 +0200 Message-ID: <5182103.61m7zJCJ6h@thomas> In-Reply-To: <20200909002247.864844-1-patrick.fu@intel.com> References: <20200909002247.864844-1-patrick.fu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v1 0/3] lib: introduce traffic mirroring lib X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Patrick Fu wrote: > Network Test Access Point (TAP) is the network monitoring service > commonly adotpted in SDN-based network infrastructures. When VMs are > inter-connected over virtual switches, TAP requires vSwitch to mirror > out network traffics from specific workload VM ports to the TAP > device/VM ports. Classical mirroring impmentations in vSwitch make an > extra copy of the source packets, which results in significant degradation > in the throughput levels vSwitch could normally archieve. Therefore, we > propose a new set of APIs to support high-throughput packet mirroring > through hardware offloading. In the RFC thread, you mentioned you were targetting vhost where there is no hardware offload. If it targets hardware offload, it should be in rte_flow. Even if no device offload, we could implement it in rte_flow. If you think it does not fit with rte_flow because it is forwarding traffic between devices, then I think rte_graph or rte_pipeline may fit. In general I am against adding a library restricted to some specific forwarding use cases.