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 E982EA054F; Mon, 1 Mar 2021 13:21:28 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D4F9222A27D; Mon, 1 Mar 2021 13:21:28 +0100 (CET) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by mails.dpdk.org (Postfix) with ESMTP id 8665322A257 for ; Mon, 1 Mar 2021 13:21:27 +0100 (CET) Received: from tanguero.localdomain (unknown [95.82.135.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 36E36400052; Mon, 1 Mar 2021 13:21:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1614601287; bh=xV7yDH/t0jHP6daVMBDawW5n4ZeWVqHv5U6znA3ccI8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ru6hm24yu6tIHn8jbMXsYnvcY3oGJuZyuN7UPLq4N6c4fnIQ/c4QFZSsnXB+oQ6bN g5m+aW7qOgewu/SBQMQvznBNk0+VhjpB/1EvOSdQJEkdYhehL5z/mhsrp0A/hbDpNI Gr7l0i++152CwS3FroySpXJyGLzXn08xD1avaf5Vf4g2fMhCU+JVk+Tj9j8QOZnRAN 5S5WSLbcg5aFQUnJXlN5fbsAr2swCd4aT2UzbOdg4FHGRjp3lqCU31B3MBlQFaZjzG HoS0iSkhFeUbVmw07KRy4GdEAv3/UOg3bsQYzqj6d43GgECWyJLAucIkJICd7QbMD1 31mMlLHhaDxHg== Date: Mon, 1 Mar 2021 13:21:26 +0100 From: Jan Viktorin To: Asaf Penso Cc: "dev@dpdk.org" , Ori Kam , "Jiawei(Jonny) Wang" , Slava Ovsiienko Message-ID: <20210301132126.437df4df@tanguero.localdomain> In-Reply-To: References: <20200918145618.052ee504@tanguero.localdomain> Organization: CESNET MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Hello Asaf, it is a while we were in touch regarding this topic. Finally, I am again trying to get work this feature. I've seen that sampling is already upstreamed which is great. However, I am not very successful with that. There is nearly no documentation, just [1], I found no examples, just commit logs... I tried: > set sample_actions 0 port_id id 1 / end > flow validate 0 ingress pattern end actions sample ratio 1 index 0 / drop / end port_flow_complain(): Caught PMD error type 1 (cause unspecified): port id action is valid in transfer mode only: Operation not supported > flow validate 0 ingress transfer pattern end actions sample ratio 1 index 0 / drop / end port_flow_complain(): Caught PMD error type 1 (cause unspecified): (no stated reason): Operation not supported Using CentOS 7, DPDK 20.11.0, OFED-5.2-1.0.4. NICs: MT2892 Family [ConnectX-6 Dx] 101d (fw 22.28.1002), MT27800 Family [ConnectX-5] 1017 (fw 16.27.2008). My primary goal is to be able to deliver exactly the same packets both to DPDK and to the Linux kernel. Doing this at RTE Flow level would be great due to performance and transparency. Jan [1] https://doc.dpdk.org/guides/prog_guide/rte_flow.html#action-sample On Fri, 18 Sep 2020 14:23:42 +0000 Asaf Penso wrote: > Hello Jan, > > You can have a look in series [1] where we propose to add APIs to DPDK20.11 for both mirroring and sampling for packets, with additional actions of the different traffic. > > [1] > http://patches.dpdk.org/project/dpdk/list/?series=12045 > > Regards, > Asaf Penso > > >-----Original Message----- > >From: dev On Behalf Of Jan Viktorin > >Sent: Friday, September 18, 2020 3:56 PM > >To: dev@dpdk.org > >Subject: [dpdk-dev] Duplicating traffic with RTE Flow > > > >Hello all, > > > >we are looking for a way to duplicate ingress traffic in hardware. > > > >There is an example in [1] suggesting to insert two fate actions into the RTE Flow > >actions array like: > > > > flow create 0 ingress pattern end \ > > actions queue index 0 / void / queue index 1 / end > > > >But our experience is that PMDs reject two fate actions (tried with mlx5). Another > >similar approach would be to deliver every single packet into two virtual > >functions: > > > > flow create 0 ingress pattern end \ > > actions vf index 0 / vf index 1 / end > > > >Third possibility was to use passthru: > > > > flow create 0 ingress pattern end \ > > actions passthru / vf index 0 / end > > flow create 0 ingress pattern end \ > > actions vf index 1 / end > > > >Again, tried on mlx5 and it does not support the passthru. > > > >Last idea was to use isolate with passthru (to deliver both to DPDK application > >and to the kernel) but again there was no support on mlx5 for passthru... > > > > flow isolate 0 true > > flow create 0 ingress pattern end actions passthru / rss end / end > > > >Is there any other possibility or PMD+NIC that is known to solve such issue? > > > >Thanks > >Jan Viktorin > > > >[1] > >https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.dpdk > >.org%2Fguides%2Fprog_guide%2Frte_flow.html%23table-rte-flow-redirect- > >queue-5- > >3&data=02%7C01%7Casafp%40nvidia.com%7C1a46005bec5245e729e708d > >85bd24caf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6373603060 > >73519816&sdata=EOF%2Fz62crvBZK8rwzwKIWxj5cVlfPVnU3FLmcL9X2w0%3 > >D&reserved=0