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 5CE8DA052B; Thu, 30 Jul 2020 08:32:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 928FAE07; Thu, 30 Jul 2020 08:32:58 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id E9CBF255 for ; Thu, 30 Jul 2020 08:32:56 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 308AD580274; Thu, 30 Jul 2020 02:32:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 30 Jul 2020 02:32:56 -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=fm1; bh= kedQo7vtVW3zUXB3Tc7CoQWe0Gp4ldl1cTuCzKcKDcE=; b=pQ9eBDDmkz8ntZs8 XCbU8Ubjhl84drB1jcReCVkL188gbP5HZ5UQ5Jz6wZ35TfCyC5X3nixNlK4I2V1g BHOSBD26a6bAaC7eh4TqB8vHE7C4lKFdSFlsOHTx3y4CJxBsKndygScBwEzOtAUc 7lfY23s5cjo6uPAHFmswRvDhXndaXOB9j2QwD6fKAAQBWIUS2zpB/aia1ekNc4sZ Em8Vkm5iWNhJ+Xc+ZOSeQ6Hwf7H5PTIgCjPCMKOaUYzjQaVlFapXJmidzqYrqSVI 1n2F6+FZJTixiERLQcLluic/faTFI9kowNGphIE7nKGYTgCu88wAalJKiKMkjdQT f918iA== 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=kedQo7vtVW3zUXB3Tc7CoQWe0Gp4ldl1cTuCzKcKD cE=; b=LeJvqo4uFiteanjLxJYWMqoaEbco1LDhfznrO8Lknh964l86Fqc5VIlVY cnUK/sJpGubrGFgHlh2m1BCaxvOOhvduYjcQTMc1nVSQ3lNL4Ber2NxfSALCO69O teMMD9Ophnihp1/FN9QkMPU2pcl+Xq9xagoSEffZEdFWdDyB6W5YwEUen4Sg5YjF kGLDyzrRSpszmeC9h8O4Nu9r0D5UBubS154bsgvaUe6u0jnKBYSzqF7spGe5uhb4 TEX57zbu4yt5pyTf49HhLs7r3xu9KOXtNMb9IT/8CH7csiN9UnkMXm1k5tjQwwFz lBjiUEwHR8Jpn4pA6d1kvD4c+XjOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieehgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedvvdejieegteegveekgeejtdduvdffieefhefgkeekjefggfevudei udejudekudenucffohhmrghinhepihgvvggvrdhorhhgpdhoiihlrggsshdrohhrghdpug hpughkrdhorhhgnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrg hlohhnrdhnvght 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 3641630600A6; Thu, 30 Jul 2020 02:32:54 -0400 (EDT) From: Thomas Monjalon To: patrick.fu@intel.com Cc: dev@dpdk.org, ferruh.yigit@intel.com, maxime.coquelin@redhat.com, bruce.richardson@intel.com, zhihong.wang@intel.com, liang-min.wang@intel.com, konstantin.ananyev@intel.com, timothy.miskell@intel.com, cunming.liang@intel.com, arybchenko@solarflare.com, Jiawei Wang , orika@mellanox.com Date: Thu, 30 Jul 2020 08:32:52 +0200 Message-ID: <9050775.XvCxKblxuy@thomas> In-Reply-To: <20200730032332.3742259-1-patrick.fu@intel.com> References: <20200730032332.3742259-1-patrick.fu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] lib: introduce traffic mirroring API 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" 30/07/2020 05:23, Patrick Fu: > 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. > > The proposal is consisted of three major parts: > - Mirror registration APIs > - Mirror offload/customization callbacks > - Shared mirror data path > > In this proposal, mirroring happens between a pair of ethdev ports (one for > the source port and the other for the mirror port), which is configurable > on a per-port per-direction basis. i.e. applications invoke the mirroring > API to register source ports and traffic directions (tx or rx). The > registration API will then attach the mirror data path to the source port > as a standard ethdev tx or rx callback. If any custom mirror offload > functions are specified by applications, the offload function will be > executed within the mirror data path. > > The mirror data path intercepts the packets flowing over the registered > source ports and, rather than doing extra packets copy operations, simply > transmits packets to the destination (mirror) port with an incremented > mbuf reference count. In this way, an identical copy of the packet data is > transmitted to both the mirror port and the original traffic destination. > > In addition, with the proposed APIs we can implement even more complicated > mirrorings scenarios. Two examples include flow based mirroring and MAC > address matching, both of which have common usage within the industry. > > Mirror registration API proto-types are defined as follows: > int rte_mirror_register(uint16_t src_port, > struct rte_mirror_param *param); > int rte_mirror_unregister(uint16_t src_port); > > struct rte_mirror_param contains all of the parameters the mirror data > path will use, e.g. the mirror port number, the source traffic direction > to be mirrored, the custom mirroring offload function pointer, the > application context, etc. Notablely, applications should passdown a > spinlock through this structure, which is used to synchronize the packet > data access between application and the mirror data path. > > Our prior studies demonstrate that this methedology is capble of doubling > the mirroring performance as compared to the default OVS port mirroring > performance (refer to the paper in IEEE xplore for further details: > https://ieeexplore.ieee.org/document/9110293) > An OVS implementation was also suggested to the OVS community for review > and comments (refer to the following OVS RFC patch: > https://patchwork.ozlabs.org/project/openvswitch/patch/ > 1595596858-78846-2-git-send-email-emma.finn@intel.com/) > > We are considering implementing the mirroring APIs as a standalone library > in DPDK, but it's also reasonble to place it inside ethdev layer or within > the vhost-pmd considering the potential usage scenarios. > > Signed-off-by: Liang-min Wang > Signed-off-by: Patrick Fu > Signed-off-by: Timothy Miskell I assume you consider deprecating rte_eth_mirror_rule_set() http://doc.dpdk.org/api/rte__ethdev_8h.html#a1c88c5e86f0358981443600f05069091 Please consider reviewing this implementation in rte_flow: https://patches.dpdk.org/patch/73279/