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 24E54A0350; Fri, 26 Jun 2020 12:46:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0824E1BE95; Fri, 26 Jun 2020 12:46:03 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 162781B951 for ; Fri, 26 Jun 2020 12:46:01 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 5D85D5802A6; Fri, 26 Jun 2020 06:46:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 26 Jun 2020 06:46:00 -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= uBGl+j58H1GfJRni+yW2defJwmqzeo7uicOVcUJZkLo=; b=eianl4TnMxSGLCYX INhkEkO5+baMv74hXAH82ePiiALu8HVhNDJKIC0RMSQJk8FUxh4hJO2Ra5vq/NkT gJ6p8GRhLeSBVGoGsPlo/EGjBI6+H7BaXELeO3Ona/GBarHcTP+8xXP4toOQPiZ1 j60MxQjD7evLm37xmjl1x0sbwNuun2cyCZhSHT72tIZ9x4X5ZW05XFX5ij4b21CQ C9e/vN+y4sqoKrH+hAWL3ceiUKG8o2tSkXBHA+9/2NIoaBjqsCsxA/MGaAIR8paF DiIfQQfUF2VBHQOSC/L/42A7o+zFm+lmHfNBcLJOyEaQ/Kn6/JKKOnEOOgfSnXZS VYRrtQ== 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=uBGl+j58H1GfJRni+yW2defJwmqzeo7uicOVcUJZk Lo=; b=gWCB0wa/LcMZCWNkGGBb1Qby4yDP3ISpZW00hwbpymfJXcKArSqDy6JD/ 0zPiWqe+NTaeuhtMfNkUNAA5yADKAt0UHbURSZSzJOD+AlXNzITHkDP/1Zd+brV/ ZN9AVHHrIHzgmo4KONW72fJ4BtaG3rW4f0yJmC7ze+9jDq+lrE1B4Ji1q6+ZjSbO 2pN0I4sSavvTf5fBpsVkda9UG76bz4jvx28uHlllCOe0VCjqiEd3F7GN0dHqAbgc gF/u2NWU8Ib8BSD8snrdAmxj505WVyTpJfLMLtmH8j8pVbhw4YLFZS+ZRZ1Gt5j5 Wk/6egy+vPQ7Kzq9bT1Jmyfxx9n1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeluddgfeegucetufdoteggodetrfdotf 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 3D1D03280063; Fri, 26 Jun 2020 06:45:58 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Jiawei Wang , Ori Kam , Slava Ovsiienko , Matan Azrad , dpdk-dev , Raslan Darawsheh , ian.stokes@intel.com, fbl@redhat.com, ferruh.yigit@intel.com, arybchenko@solarflare.com Date: Fri, 26 Jun 2020 12:45:57 +0200 Message-ID: <7719744.nB5e5IOROX@thomas> In-Reply-To: References: <1593102379-400132-1-git-send-email-jiaweiw@mellanox.com> <17660414.AQMWyGVKyv@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow 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" 26/06/2020 12:35, Jerin Jacob: > On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon wrote: > > > > 25/06/2020 19:55, Jerin Jacob: > > > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang wrote: > > > > > > > > When using full offload, all traffic will be handled by the HW, and > > > > directed to the requested vf or wire, the control application loses > > > > visibility on the traffic. > > > > So there's a need for an action that will enable the control application > > > > some visibility. > > > > > > > > The solution is introduced a new action that will sample the incoming > > > > traffic and send a duplicated traffic in some predefined ratio to the > > > > application, while the original packet will continue to the target > > > > destination. > > > > > > > > The packets sampled equals is '1/ratio', if the ratio value be set to 1 > > > > , means that the packets would be completely mirrored. The sample packet > > > > can be assigned with different set of actions from the original packet. > > > > > > > > In order to support the sample packet in rte_flow, new rte_flow action > > > > definition RTE_FLOW_ACTION_TYPE_SAMPLE and structure rte_flow_action_sample > > > > > > Isn't mirroring the packet? How about, RTE_FLOW_ACTION_TYPE_MIRROR > > > I am not able to understand, Why it is called sample. > > > > Sampling is a partial mirroring. > > I think, By definition, _sampling_ is the _selection_ of items from a > specific group. > I think, _sampling_ is not dictating, what is the real action for the > "selected" items. > One can get confused with the selected ones can be for forward, drop > any other action. I see. Good design question (I will let others reply). > So IMO, explicit mirror keyword usage makes it is clear. > > Some more related questions: > 1) What is the real use case for ratio? I am not against adding a > ratio attribute if the MLX hardware supports it. It will be good to > know the use case from the application perspective? And what basics > application set ratio != 1? If I understand well, some applications want to check, by picking random packets, that the processing is not failing. > 2) If it is for "rate-limiting" or "policing", why not use rte_mtr > object (rte_mtr.h) via rte_flow action. > 3) One of the issue for driver developers and application writers are > overlapping APIs. This would overlap with rte_eth_mirror_rule_set() > API. > > Can we deprecate rte_eth_mirror_rule_set() API? It will be a pain for > all to have overlapping APIs. We have not fixed the VLAN filter API > overlap with rte_flow in ethdev. Its being TODO for multiple releases > now. Ooooooooh yes! I think flow-based API is more powerful, and should deprecate old port-based API. I want to help deprecating such API in 20.11 if possible. > > Full mirroring is sampling 100% packets (ratio = 1). > > That's why only one action is enough.