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 6D742A0350; Mon, 29 Jun 2020 15:12:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 56B301BEB7; Mon, 29 Jun 2020 15:12:22 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 71E2E1BEB5 for ; Mon, 29 Jun 2020 15:12:20 +0200 (CEST) Received: from mx1-us1.ppe-hosted.com (unknown [10.7.65.62]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id C277C60072; Mon, 29 Jun 2020 13:12:19 +0000 (UTC) Received: from us4-mdac16-75.ut7.mdlocal (unknown [10.7.64.194]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id C13778009B; Mon, 29 Jun 2020 13:12:19 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.66.32]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id EE9E128004D; Mon, 29 Jun 2020 13:12:18 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 1C679B4005F; Mon, 29 Jun 2020 13:12:18 +0000 (UTC) Received: from [192.168.38.17] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 14:12:11 +0100 To: Ori Kam , "Jiawei(Jonny) Wang" , Slava Ovsiienko , Matan Azrad CC: "dev@dpdk.org" , Thomas Monjalon , Raslan Darawsheh , "ian.stokes@intel.com" , "fbl@redhat.com" , Adrien Mazarguil References: <1593102379-400132-1-git-send-email-jiaweiw@mellanox.com> <1593102379-400132-2-git-send-email-jiaweiw@mellanox.com> <58ad214a-652e-a40f-d602-c035df7bcfa7@solarflare.com> From: Andrew Rybchenko Autocrypt: addr=arybchenko@solarflare.com; keydata= mQINBF2681gBEACbdTxu8eLL3UX2oAelsnK9GkeaJeUYSOHPJQpV7RL/iaIskqTwBRnhjXt7 j9UEwGA+omnOmqQMpeQTb/F9Ma2dYE+Hw4/t/1KVjxr3ehFaASvwR4fWJfO4e2l/Rk4rG6Yi 5r6CWU2y8su2654Fr8KFc+cMGOAgKoZTZHZsRy5lHpMlemeF+VZkv8L5sYJWPnsypgqlCG3h v6lbtfZs+QqYbFH6bqoZwBAl5irmxywGR7ZJr1GLUZZ1lfdazSY8r6Vz0/Ip/KVxGu2uxo81 QCsAj0ZsQtwji9Sds/prTiPrIjx8Fc/tfbnAuVuPcnPbczwCJACzQr4q26XATL3kVuZhSBWh 4XfO/EAUuEq5AemUG5DDTM87g7Lp4eT9gMZB6P+rJwWPNWTiV3L7Cn+fO+l9mTPnOqdzBgDe OaulKiNSft1o0DY4bGzOmM2ad2cZt0jfnbMPMTE9zsr6+RFa+M8Ct20o6U1MUE4vP6veErMK of4kZ8PdoMM+Sq1hxMPNtlcVBSP9xMmdSZPlfDYI5VWosOceEcz7XZdjBJKdwKuz70V7eac4 ITSxgNFCTbeJ03zL2MR5s0IvD9ghISAwZ6ieCjU5UATn5+63qpD0nVNLsAdb/UpfvQcKAmvj 0fKlxu/PMVkjBa7/4cfNogYOhWDKUO+1pMaFwvb6/XTo6uMpfQARAQABtCxBbmRyZXcgUnli Y2hlbmtvIDxhcnliY2hlbmtvQHNvbGFyZmxhcmUuY29tPokCVAQTAQoAPhYhBP6NPgcKRj/Y X0yXQahue0sAy4m+BQJduvNYAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKhue0sAy4m+t3gP/j1MNc63CEozZo1IZ2UpVPAVWTYbLdPjIRdFqhlwvZYIgGIgIBk3ezKL K0/oc4ZeIwL6wQ5+V24ahuXvvcxLlKxfbJ6lo2iQGC7GLGhsDG9Y2k6sW13/sTJB/XuR2yov k5FtIgJ+aHa1PDZnepnGGOt9ka9n/Jzrc9WKYapOIIyLRe9U26ikoVgyqsD37PVeq5tLWHHA NGTUKupe9G6DFWidxx0KzyMoWDTbW2AWYcEmV2eQsgRT094AZwLFN5ErfefYzsGdO8TAUU9X YTiQN2MvP1pBxY/r0/5UfwV4UKBcR0S3ZvzyvrPoYER2Kxdf/qurx0Mn7StiCQ/JlNZb/GWQ TQ7huduuZHNQKWm7ufbqvKSfbPYvfl3akj7Wl8/zXhYdLqb5mmK45HXrgYGEqPN53OnK2Ngx IgYKEWr05KNv09097jLT5ONgYvszflqlLIzC4dV245g7ucuf9fYmsvmM1p/gFnOJBJL18YE5 P1fuGYNfLP+qp4WMiDqXlzaJfB4JcinyU49BXUj3Utd6f6sNBsO8YWcLbKBV9WmA324S3+wj f4NPRp3A5E+6OmTVMLWire2ZvnYp3YvifUj1r8lhoZ2B2vKuWwiTlHOKYBEjnOQJQnqYZEF0 JQQ1xzVDBQKE01BPlA3vy6BGWe6I4psBVqMOB9lAev/H+xa4u6Z3uQINBF269JsBEAC2KB3W 8JES/fh74avN7LOSdK4QA7gFIUQ4egVL81KnxquLzzilABuOhmZf3Rq6rMHSM8xmUAWa7Dkt YtzXStjEBI/uF0mAR3mMz1RcL2Wp+WD/15HjVpA7hPjXSEsWY0K2ymPerK4yrLcfFTHdMonY JfuACCC9NtOZxrWHOJoUS+RT7AWk80q/6D2iwQ47/2dBTznVG+gSeHSes9l91TB09w6f9JX/ sT+Ud0NQfm7HJ7t2pmGI9O6Po/NLZsDogmnIpJp/WwYOZN9JK7u2FyX2UyRzR8jK42aJkRsh DXs16Cc2/eYGakjrdO3x9a+RoxN7EuFtYhGR1PzMXdUiB5i+FyddYXkYUyO43QE/3VPA5l1v TUOagzZq6aONsdNonGJkV3TIG3JmUNtM+D/+r6QKzmgoJ8w576JxEZI09I/ZFN+g7BnUmlMx 6Z3IUOXVX/SWfGFga0YajwajHz03IBhChEbYbbqndVhmshu2GFURxrfUPYWdDXEqkh+08a5U Didia9jm2Opv4oE1e1TXAePyYJl/Zyps4Cv00GObAxibvMBQCUZQ+IBnNldRBOwXXRQV2xpx P+9iO1VYA/QXn0KqRK+SH1JGRXbJYi42YFaW1gE0EU0fiR2Wb9pK+doNEjjOhlzUGuvOEAUS +4m0m3dlfEvpCV9GMr7ERRpZzh9QkQARAQABiQI8BBgBCgAmFiEE/o0+BwpGP9hfTJdBqG57 SwDLib4FAl269JsCGwwFCQlmAYAACgkQqG57SwDLib7x6g//e+eCtNnJz7qFGbjWRJYNLCe5 gQwkhdyEGk4omr3VmjGj3z9kNFy/muh4pmHUngSAnnpwZggx14N4hhKf9y8G4Dwvsqa6b1zB Jq/c4t/SBDtGW4M/E331N04PaQZpcrbTfp1KqHNknk2N7yOk4CcoLVuIZmA5tPguASV8aAfz ZwhWAwn6vUEw9552eXEAnGFGDTCbyryNwzB5jtVQOEEDjTxcCkpcXMB45Tb1QUslRTu/sBAe HhPCQSUcJHR+KOq+P6yKICGAr291PZd6Qc7C3UyE+A3pY/UfdEVWj0STBWx1qvYLaHLrI4O9 KXDgh7luLjZZafcueCaPYmNo4V2lmNb3+7S4TvqhoZS+wN+9ldRQ4gH3wmRZybN6Y/ZCqxol RaZpE3AqdWsGvIgAkD0FpmtZNii9s2pnrhw0K6S4t4tYgXGTossxNSJUltfFQZdXM1xkZhtv dBZuUEectbZWuviGvQXahOMuH2pM64mx2hpdZzPcI2beeJNHkAsGT2KcaMETgvtHUBFRlLVB YxsUYz3UZmi2JSua4tbcGd6iWVN90eb8CxszYtivfpz6o2nPSjNwg0NaVGSHXjAK0tdByZ9t SkwjC3tEPljVycRSDpbauogOiAkvjENfaPd/H26V5hY822kaclaKDAW6ZG9UKiMijcAgb9u5 CJoOyqE8aGS5Ag0EXbr1RwEQAMXZHbafqmZiu6Kudp+Filgdkj2/XJva5Elv3fLfpXvhVt0Y if5Rzds3RpffoLQZk9nPwK8TbZFqNXPu7HSgg9AY7UdCM94WRFTkUCGKzbgiqGdXZ7Vyc8cy teGW+BcdfQycDvjfy50T3fO4kJNVp2LDNdknPaZVe8HJ80Od63+9ksB6Ni+EijMkh6Uk3ulB CSLnT4iFV57KgU2IsxOQVLnm+0bcsWMcCnGfphkY0yKP+aJ6MfmZkEeaDa7kf24N14ktg50m vOGDitcxA/+XXQXOsOIDJx1VeidxYsQ2FfsKu1G8+G6ejuaLf4rV5MI/+B/tfLbbOdikM5PF pxZVgTir9q13qHumMxdme7w5c7hybW412yWAe9TsrlXktFmFjRSFzAAxQhQSQxArS6db4oBk yeYJ59mW52i4occkimPWSm/raSgdSM+0P6zdWUlxxj+r1qiLgCYvruzLNtp5Nts5tR/HRQjE /ohQYaWDSVJEsc/4eGmgwzHzmvHtXeKkasn01381A1Lv3xwtpnfwERMAhxBZ8EGKEkc5gNdk vIPhknnGgPXqKmE1aWu8LcHiY+RHAF8gYPCDMuwyzBYnbiosKcicuIUp0Fj8XIaPao6F+WTi In4UOrqrYhsaCUvhVjsTBbNphGih9xbFJ8E+lkTLL8P3umtTcMPnpsB4xqcDABEBAAGJBHIE GAEKACYWIQT+jT4HCkY/2F9Ml0GobntLAMuJvgUCXbr1RwIbAgUJCWYBgAJACRCobntLAMuJ vsF0IAQZAQoAHRYhBNTYjdjWgdaEN5MrAN+9UR5r/4d3BQJduvVHAAoJEN+9UR5r/4d3EiQP /3lyby6v49HTU94Q2Fn2Xat6uifR7kWE5SO/1pUwYzx6v+z5K2jqPgqUYmuNoejcGl0CTNhg LbsxzUmAuf1OTAdE+ZYvOAjjKQhY4haxHc4enby/ltnHfWJYWJZ9UN5SsIQLvITvYu6rqthO CYjpXJhwkj3ODmC9H1TrvjrBGc6i7CTnR8RCjMEwCs2LI2frHa4R6imViEr9ScMfUnzdABMQ B0T5MOg8NX92/FRjTldU2KovG0ML9mSveSvVHAoEBLy4UIs5nEDdNiO1opJgKb5CXvWQugub 7AR52phNdKVdEB0S4tigJT4NalyTaPiUhFEm+CzZpMQDJ5E+/OowaPRfN4HeJX+c8sB+vUAZ mkAaG75N+IEk5JKFK9Z+bBYgPgaBDFZYdWDB/TMH0ANt+KI5uYg0i12TB4M8pwKG1DEPUmWc F2YpvB3jnbwzsOpSFiJOOlSs6nOB0Sb5GRtPOO3h6XGj+6mzQd6tcL63c9TrrUkjq7LDkxCz SJ2hTYRC8WNX8Uw9skWo5728JNrXdazEYCenUWmYiKLNKLslXCFodUCRDh/sUiyqRwS7PHEA LYC/UIWLMomI0Yvju3KA5v3RQVXhL+Gx2CzSj3GDz9xxGhJB2LfRfjzPbTR/Z27UpjCkd8z0 Ro3Ypmi1FLQwnRgoOKDbetTAIhugEShaLTITzJAP/iRDJCQsrZah5tE8oIl81qKEmBJEGcdt HYikbpQe7ydcXhqTj7+IECa3O7azI5OhCxUH2jNyonJ/phUslHH2G1TTBZK8y4Hrx5RpuRNS esn3P9uKu9DHqBAL7DMsCPwb2p1VNnapD72DBmRhzS/e6zS2R4+r9yNv03Hv7VCxKkmtE63H qpS//qpjfrtsIcHAjnKDaDtL1LYCtHoweI+DOpKKULSAYp/JE6F8LNibPQ0/P3S5ZIJNC4QZ uESjFOalJwFIqGQdkQB7ltRNJENLrHc+2jKGOuyFHm/Sbvp5EMGdaeQ0+u8CY0P+y6oXenwx 7WrJz/GvbNoFhJoJ6RzxCMQrFgxrssVZ7w5HcUj94lbnJ6osdYE/WpSd50B6jet6LKh5revg u9XI9CoqsPQ1V4wKYYdllPuogCye7KNYNKuiiuSNpaF4gHq1ZWGArwZtWHjgc2v3LegOpRQF SwOskMKmWsUyHIRMG1p8RpkBQTqY2rGSeUqPSvaqjT0nq+SUEM6qxEXD/2Wqri/X6bamuPDb S0PkBvFD2+0zr5Bc2YkMGPBYPNGZiTp3UjmZlLfn3TiBKIC92jherY563CULjSsiBEJCOSvv 4VPLn5aAcfbCXJnE3IGCp/hPl50iQqu7BPOYBbWXeb9ptDjGCAThNxSz0WAXkmcjAFE8gdE6 Znk9 Message-ID: <48fa20a4-2288-bbda-a8aa-0e0e83ec527d@solarflare.com> Date: Mon, 29 Jun 2020 16:11:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.17.10.39] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1020-25510.003 X-TM-AS-Result: No-22.798900-8.000000-10 X-TMASE-MatchedRID: 8HTFlOrbAtFkoLIVEg4xZa0Ax9flq7A4KWPnYJ5Ay2qZt08TfNy6OP6Y Y1MXmqne8HOc+gY1idvMWnFrAD4CE711oEygt0cU9m9PbNihg7C3dp6DuD+6wC62hjZS0WoYy/Y 4v+Jp8XeVLtDUy12Wh/ry/O+gcknREPI1TSE7G1sea0JeKHt/0wZyESFXAljfAI4sP5ySAofxt2 sUlvdsdqqF4LjCRIFn8EPdhTcCnGFDyFDttIdo/O2QUW0UWe1aSMKL21+E+NBZ+YxyNxdzRz3gO cwksVBJHHJvx0TF4QyqV/6zH+TDff6tiMB4nmlb6zi8j+r17t2D33mO/UVvM/I35cQSjJK+492k MsW7j2Lz39bev2BML6rIcrk2tmeXgKLoPFWEUIdFM72aEhcbjY1j+mrGi/PFjFFYmmGGytxQjev vFeK6vZJDQ9c8vBDSvjRMbEXhu4TKdq5Cxg5pYwi0LLplf+UvX8dQF/SzGRk4XREg9Ki109WZDZ Fp9sK+JRxsfynP2gimj4XPy3K74xHzG0HT5tBbVV4ZZmbE3YwacZilk37ECEvEK4FMJdoqEqzgv jGP3sKiK67Vkw5lvzyTiCXZ8fjk8mlg3ZRQcwdsivAOGSeMWcGcvcBoab2jlv3B8RZ1mhjUv0EL gC9CcvoSRTSXUKtz7oahxnQTPdEM5WJq5oHS2RlJRfzNw8afS3sNHVAxomxKDy5+nmfdPpXBzAs lgCOzRkRqiaaL2qoSn4xJejKRAxspN4FbPOcmSHCU59h5KrECn5QffvZFlYaMPFsKFv3QUIztj8 SGkJ49JuF36cEwTkAc/5igkzBmNZgeA8Gk1daeAiCmPx4NwFkMvWAuahr89yEa3tvzanYXeuQCq IxlebxAi7jPoeEQftwZ3X11IV0= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--22.798900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1020-25510.003 X-MDID: 1593436339-4kUzK9qVd8MX 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" Hi all, CC Adrien (I apologize for pulling you to the rte_flow API discussions once again, but may be you can find spare time and share your thoughts. Your opinion as an author and architect of the rte_flow API would be very useful and highly appreciated.) On 6/29/20 2:40 PM, Ori Kam wrote: > Hi all, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Sunday, June 28, 2020 7:19 PM >> To: Jiawei(Jonny) Wang ; Ori Kam >> ; Slava Ovsiienko ; Matan >> Azrad >> Cc: dev@dpdk.org; Thomas Monjalon ; Raslan >> Darawsheh ; ian.stokes@intel.com; fbl@redhat.com >> Subject: Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte >> flow >> >> On 6/28/20 7:16 PM, Jiawei(Jonny) Wang wrote: >>> >>> On Sunday, June 28, 2020 4:27 PM, Andrew Rybchenko >> wrote: >>>> >>>> On 6/25/20 7:26 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 will be introduced. >>>>> >>>>> Signed-off-by: Jiawei Wang >>>> >>>> [snip] >>>> >>>>> @@ -2709,6 +2716,28 @@ struct rte_flow_action { struct rte_flow; >>>>> >>>>> /** >>>>> + * @warning >>>>> + * @b EXPERIMENTAL: this structure may change without prior notice >>>>> + * >>>>> + * RTE_FLOW_ACTION_TYPE_SAMPLE >>>>> + * >>>>> + * Adds a sample action to a matched flow. >>>>> + * >>>>> + * The matching packets will be duplicated to a special queue or >>>>> +vport >>>>> + * in the predefined probabiilty, All the packets continues >>>>> +processing >>>>> + * on the default flow path. >>>>> + * >>>>> + * When the sample ratio is set to 1 then the packets will be 100% >>>> mirrored. >>>>> + * Additional action list be supported to add for sampled or mirrored >>>> packets. >>>>> + */ >>>>> +struct rte_flow_action_sample { >>>>> + /* packets sampled equals to '1/ratio' */ >>>>> + const uint32_t ratio; >>>>> + /* sub-action list specific for the sampling hit cases */ >>>>> + const struct rte_flow_action *actions; >>>> >>>> This design idea does not look good to me from the very beginning. IMHO it >>>> does not fit flow API overall design. >>>> I mean sub-action list. >>>> >>>> As I understand Linux iptables solves it on match level (i.e. in pattern). E.g. >>>> "limit" extension which is basically sampling. Sampling using meta pattern >>>> item in combination with PASSTHRU action (to make sampling actions non- >>>> terminating if required) is a better solution from design point of view. >>> >>> On our design, there're sample flow path and normal flow path, each path >> can have different actions. >>> The defined sub-actions list only applied for sampled packets in the sample >> flow path; >>> For normal path, all packets will continue to go with the original actions. >>> >> >> In my too. > > First as far as I know TC works close to the suggest approach (that by itself doesn’t mean anything) > The concept of a PASSTHRU is a good one but it has some issue to consider: > 1. When using PASSTHRU it will mean that the matching part will be needed to be checked > more times this will have performance penalty , also number of HW have limited number of flow that can be offload > this will approach will waste resources. Marking or tagging could be used to address it. E.g. target traffic could be tagged first, then matching by tag should be used to sample and to do HW offloads. Moreover, mapping of rte_flow API rules into HW rule is not required to be 1-to-1. Yes, 1-to-1 is simple, but it could be more complicated 1-to-N (when one rte_flow API rule is represented by many HW rules) or N-to-1 (when few flow API rules are represented as one HW rule) or even N-to-M. For example, tagging which is not visible outside, could be purely SW and used to build such constructions in SW. It is an implementation detail is out of scope of the generic API definition. Yes, it sounds like over-complicating, but I really dislike above sub-action list from design point of view and that's why I"m trying to think in different directions. > 2. Using PASSTHRU will force the order of flows (sure it can be done using priorities but it is more complex to > the application to implement) See above. > 3. PASSTHRU will mean that there will be 2 terminal action for each flow (for example queue index 2 / passthru) > this also is not native to RTE flow. Sorry, but there are two branches for terminating actions in the sampling action design anyway (yes, internal/hidden). You need two copies of the packet, so whatever you do it will be two terminating actions. > 4. since we want to select only part of the packets, and we want to have some of the actions done on both > packets (the sampled and the standard one) and then we want on the sampled packet do some specific actions > while on the standard packet do different actions. Yes, it is not a problem with PASSTHRU. > Lest check the following use case: > Application is using full offload traffic from the wire to a VM, which should decaped > So the basic flow is: > Flow create 0 transfer ingress pattern eth / outer.ip =x / end actions decap / port id 3 > Since after the offload the application loses visibility of the traffic. it still wants to sample some of the traffic > in order to verify that the traffic is valid. So the application request to receive some of the original traffic and > mark it with id. > > If we use the original approach (the one in the patch) we will need something like this: > Flow 1: flow create 0 transfer ingress pattern eth / outer.ip=x / end actions sample(ratio 2, actions mark id 3 / port pf)) / decap / port 3 > > In the PASSTHRU concept (I'm not sure I can even create such flows) > Flow 1: flow create 0 transfer ingress pattern eth / outer.ip =x / end actions decap / port 2 /passtthru // original request > Flow 2: flow create 0 transfer ingress pattern eth/ outer.ip=x / should sample (new item that selects if the packet is selected based on the ratio)end act / mark / port pf > > The main issue with this case the decap is before the sample so the sample will get decap packet. Order should be simply different: first sampling with pass- through, second decap and deliver to VM. Yes, I realize that two actions with basically the same match (modulo sampling match) is not ideal for mapping to HW (even if it collapsed into trivial tag match which pre-rule to make tagging). I'm not 100% happy with it, but I'm even less happy with sub-action list design and just trying to find better alternative solution. > So when looking at everything I think the original API is the best approach. > For the record I think that passthru action is very important and should be supported but not the best one for this feature. > > Thanks, > Ori >