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 655AEA054F; Mon, 1 Mar 2021 15:43:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 052A722A2A4; Mon, 1 Mar 2021 15:43:32 +0100 (CET) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by mails.dpdk.org (Postfix) with ESMTP id F3B4D40041 for ; Mon, 1 Mar 2021 15:43:29 +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 85AC5400064; Mon, 1 Mar 2021 15:43:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1614609809; bh=Aadjbyr6fndekII0fR+85pZjO3dAMBvsl7gwXdhmHBY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZKPrYJ7vBuhwsrbyHZrB4DsD0+sOdAv3kQAzl9g+AIuBNqEFpG8JXAdjqE0YbZfGB VodmAWoQqGwPL4OWH8RAP41/9s664Xyj1bu9fu3BZDXyNOKLRhBl+YCSqrifeUdn65 yDXE/rEQHEuGiq0jgTJZD87LQgqVQwH0Nmh5e9WniMZ+DH6CqjKHUhTnIh+hmBJwJE 13yp612EMwx6BIoETB1gVZRzCeSAUE350YiiCpxDG6hsPibgBfg7BVLgW3F0QhRwP3 AYbwDcerkKOuhDyeb+j9KLS5nM4HjlMadQmh4c4J5O5o8kgFExs1JHhZED9+8pLwD8 qQf3Yi7Si+Q8Q== Date: Mon, 1 Mar 2021 15:43:26 +0100 From: Jan Viktorin To: Slava Ovsiienko Cc: Asaf Penso , "dev@dpdk.org" , Ori Kam , "Jiawei(Jonny) Wang" Message-ID: <20210301154326.344c2e1f@tanguero.localdomain> In-Reply-To: References: <20200918145618.052ee504@tanguero.localdomain> <20210301132126.437df4df@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" On Mon, 1 Mar 2021 14:34:07 +0000 Slava Ovsiienko wrote: > Hi, Jan > > To use port action (I see it is in your sample action list) the flow should be applied to the FDB domain, > ie "transfer" attribute should be specified: > > flow validate 0 ingress transfer... As you can see (however, it's a bit messy in the response below, in [1], it is better), I tried both. First without transfer and second with. The first gives hint "action is valid in transfer mode only" but the second try with transfer gives "Operation not supported". Jan [1] http://mails.dpdk.org/archives/dev/2021-March/200475.html > > With best regards, Slava > > > -----Original Message----- > > From: Jan Viktorin > > Sent: Monday, March 1, 2021 14:21 > > To: Asaf Penso > > Cc: dev@dpdk.org; Ori Kam ; Jiawei(Jonny) Wang > > ; Slava Ovsiienko > > Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow > > > > 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%7C1a46005bec5245e729e70 > > 8d > > > > > >85bd24caf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63736030 > > 60 > > > > > >73519816&sdata=EOF%2Fz62crvBZK8rwzwKIWxj5cVlfPVnU3FLmcL9X2w0 > > %3 > > > >D&reserved=0 >