DPDK usage discussions
 help / color / mirror / Atom feed
From: Tony Hart <Tony.Hart@corero.com>
To: "Jiawei(Jonny) Wang" <jiaweiw@nvidia.com>
Cc: Asaf Penso <asafp@nvidia.com>, "users@dpdk.org" <users@dpdk.org>
Subject: Re: [External] rte_flow: transfer and sample, is it possible?
Date: Mon, 13 Mar 2023 09:29:17 +0000	[thread overview]
Message-ID: <E47A945E-3B8C-4BE8-9AB0-85863CC1E6EC@corero.com> (raw)
In-Reply-To: <PH0PR12MB545182DDFA77E8BEF9DAFC3AC6BA9@PH0PR12MB5451.namprd12.prod.outlook.com>

Hi Asaf, Jonny,

Thanks for the information, that helped, the explanation of the difference between the ingress and transfer modes explains some of the errors I was seeing.

Also Jonny’s exampled worked.

I curious about isolated mode, is it more efficient to use that mode on the Connectx in terms of hardware resources?



Tony Hart | Chief Architect
Tony.Hart@corero.com <mailto:Tony.Hart@corero.com> 
 
 293 Boston Post Road West Suite 310, Marlborough, MA 01752 


Access Corero Network Security’s Privacy Policy here <www.corero.com/privacy>.



We are Corero Network Security plc (“Corero”), registered in England and Wales, with registered company number 02662978, registered office address Regus House Highbridge, Oxford Road, Uxbridge, Middlesex, UB8 1HR. Corero is the parent company for Corero Network Security, Inc. and Corero Network Security (UK) Ltd (a company registered in England and Wales with registered number 04047090, with the same registered office address as above) For information about how we process your data, or to manage your data preferences, click here <info.corero.com/data-preferences.html>. 



> On Mar 10, 2023, at 1:37 AM, Jiawei(Jonny) Wang <jiaweiw@nvidia.com> wrote:
> 
> Hi Tony,
> 
> "
> >What I’d like to do is 
> >forward packets from the physical port to the VF1 and vice versa as 
> >described in the example, in addition I’d also like to send a 1:N 
> >sample of the traffic received from the physical port to the 
> >“hypervisor application”, i.e. the DPDK app.
> "
> Under your case, DPDK attached two ports, port_id 0 is for the physical port, and port_id 1 is for VF1-rep.
> You can try the below flow rule:
> 
> # Set the sample flow rule with transfer enabled, sampled packet with 10%, and also forwarded the original packets to VF1. 
> 
> testpmd> set sample_actions 0 / end
> testpmd> flow create 0 transfer pattern represented_port ethdev_port_id is 0 / end actions sample ratio 10 index 0 / count / represented_port ethdev_port_id 1 / end
> 
> (For E-Switch Sampling flow with sample ratio > 1, additional actions are not supported in the sample actions list.)
> 
> # If DPDK working on the isolate mode, you also need to create the rx flow.
> testpmd> flow create 0 ingress pattern eth / end actions rss / count / end
> 
> Then, you should see the sampled packet in DPDK SW, and also VF1.
> 
> Thanks.
> Jonny
> 
> > -----Original Message-----
> > From: Asaf Penso <asafp@nvidia.com>
> > Sent: Friday, March 10, 2023 8:09 AM
> > To: Tony Hart <Tony.Hart@corero.com>; users@dpdk.org; Jiawei(Jonny)
> > Wang <jiaweiw@nvidia.com>
> > Subject: RE: rte_flow: transfer and sample, is it possible?
> > 
> > Hello Tony,
> > 
> > First, I'm adding @Jiawei(Jonny) Wang, who's our expert for this feature and
> > can support and elaborate more, if needed.
> > 
> > Second, I looked into your use case below and have several comments.
> > 1. In your first try, you configure the sample action to be queue, but in the
> > context of a switch (transfer) there is no meaning for a queue, only for ports.
> > This is the reason you get the failure.
> > From our documentation [1], you can see that:
> > Sample flow:
> > ...
> > For E-Switch mirroring flow, supports RAW ENCAP, Port ID,
> > VXLAN ENCAP, NVGRE ENCAP in the sample actions list.
> > 
> > 2. On your second try, there is confusion about the groups.
> > If you specify "ingress," it means you are in the domain of the NIC RX of the
> > DPDK app. If you specify "transfer" you are in the switch domain.
> > Each domain has its own tables, so when you do the following , these tables
> > don't really connect to one another:
> > 
> > flow create 0 ingress pattern end actions jump group 1 / end
> > flow create 0 ingress group 1 pattern end actions sample ratio 10
> > index 0 / count / jump group 2 / end
> > flow create 0 ingress group 2 priority 2 pattern end actions count /
> > jump group 3 / end
> > 
> > flow create 0 transfer group 2 pattern represented_port
> > ethdev_port_id is 0 / end actions count / represented_port ethdev_port_id 1 /
> > end
> > 
> > When a packet is received in the switch domain on group 0 it looks for a rule.
> > It doesn't have any so the default behavior is go to the NIC RX domain and
> > there you have sample.
> > It "works" because you configure to sample the packet to queue 0, but please
> > note the original packet is dropped since you jump to group 3 which has no
> > rules.
> > The flow in the switch is only in group 2 but there is a disconnection between
> > switch group 0 and group 2 and this is why you don't see the packet in the VF.
> > 
> > @Jiawei(Jonny) Wang, can you suggest a way to send the original packet to a
> > VF and a sample to the DPDK app?
> > 
> > [1] http://doc.dpdk.org/guides/nics/mlx5.html
> > 
> > Regards,
> > Asaf Penso
> > 
> > >-----Original Message-----
> > >From: Tony Hart <Tony.Hart@corero.com>
> > >Sent: Wednesday, 8 March 2023 17:43
> > >To: users@dpdk.org
> > >Subject: rte_flow: transfer and sample, is it possible?
> > >
> > >I’m trying to configure a simple variation on the Switch Example (14.7.
> > >Switching Examples) in the Programmer’s Guide. What I’d like to do is
> > >forward packets from the physical port to the VF1 and vice versa as
> > >described in the example, in addition I’d also like to send a 1:N
> > >sample of the traffic received from the physical port to the
> > >“hypervisor application”, i.e. the DPDK app.
> > >
> > >I have not found a way to achieve this, this is what I’ve tried...
> > >
> > >Note my DPDK ports are 0 (physical) and 1 (VF1 representer) rather than
> > >the 3 and 4 in the Programmer’s Guide example and I’m using
> > >DPDK-stable-22.11.1 with ConnectX-6 version 22.30.100 (configured in
> > switchdev mode).
> > >
> > >
> > >Setting up the example works as expected, traffic is forwarded between
> > >physical and VF1 and nothing goes to DPDK app. I used these testpmd
> > >commands...
> > >
> > >flow create 0 transfer pattern represented_port ethdev_port_id is 0 /
> > >end actions represented_port ethdev_port_id 1 / end flow create 0
> > >transfer pattern represented_port ethdev_port_id is 1 / end actions
> > >represented_port ethdev_port_id 0 / end
> > >
> > >
> > >However I haven’t been able to setup the sampling. First I tried
> > >(leaving out the VF1 to PHY setup for now)...
> > >
> > >set sample_actions 0 queue index 0 / end flow create 0 transfer pattern
> > >represented_port ethdev_port_id is 0 / end actions sample ratio 10
> > >index 0 / represented_port ethdev_port_id 1 / end
> > >
> > >>port_flow_complain(): Caught PMD error type 16 (specific action):
> > >>E-Switch doesn't support any optional action for sampling: Operation
> > >>not supported
> > >
> > >
> > >Next tried sampling after the forwarding (use priority to avoid
> > >ambiguity), I need to have a fate action on the sample line otherwise I
> > >get "no fate action is found:” error…
> > >
> > >set sample_actions 0 queue index 0 / end flow create 0 transfer
> > >priority 2 pattern represented_port ethdev_port_id is 0 / end actions
> > >represented_port ethdev_port_id 1 / end flow create 0 ingress pattern
> > >end actions sample ratio 10 index 0 / jump group 1 / end
> > >
> > >>port_flow_complain(): Caught PMD error type 1 (cause unspecified):
> > >>hardware refuses to create flow: Operation not supported
> > >
> > >
> > >I have not been able to use sampling in group 0, but seems to work in
> > >non-0 group, So…
> > >
> > >set sample_actions 0 queue index 0 / end flow create 0 ingress pattern
> > >end actions jump group 1 / end flow create 0 ingress group 1 pattern
> > >end actions sample ratio 10 index 0 / count / jump group 2 / end flow
> > >create 0 transfer group 2 pattern represented_port ethdev_port_id is 0
> > >/ end actions count / represented_port ethdev_port_id 1 / end flow
> > >create 0 ingress group 2 priority 2 pattern end actions count / jump
> > >group 3 / end
> > >
> > >
> > >No errors! And samples show up in DPDK in the 1:10 ratio expected.
> > >However there’s no forwarding between physical and VF1. The counter
> > >for the transfer rule confirms this, its 0, however the counter for the
> > >last rule shows hits (and the traffic is blocked).
> > >
> > >testpmd> flow query 0 2 count
> > >COUNT:
> > > hits_set: 1
> > > bytes_set: 1
> > > hits: 0
> > > bytes: 0
> > >testpmd> flow query 0 3 count
> > >COUNT:
> > > hits_set: 1
> > > bytes_set: 1
> > > hits: 117
> > > bytes: 7488
> > >
> > >
> > >
> > >Thanks for any help,
> > >Tony
> > >
> > >
> > >Tony Hart | Chief Architect
> > >Tony.Hart@corero.com <mailto:Tony.Hart@corero.com>
> > >
> > > 293 Boston Post Road West Suite 310, Marlborough, MA 01752
> > >
> > >
> > >Access Corero Network Security’s Privacy Policy here
> > ><www.corero.com/privacy>.
> > >
> > >
> > >
> > >We are Corero Network Security plc (“Corero”), registered in England
> > >and Wales, with registered company number 02662978, registered office
> > >address Regus House Highbridge, Oxford Road, Uxbridge, Middlesex, UB8
> > >1HR. Corero is the parent company for Corero Network Security, Inc. and
> > >Corero Network Security (UK) Ltd (a company registered in England and
> > >Wales with registered number 04047090, with the same registered office
> > >address as above) For information about how we process your data, or to
> > >manage your data preferences, click here <info.corero.com/data-
> > preferences.html>.
> > >
> > >
> 


  reply	other threads:[~2023-03-13  9:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5644d4d8-d47b-4a0c-84ec-17ce8d68d922.8b1a23e8-b9b9-4aca-a31a-0d4e4655acbd.64a2ee37-3c38-431e-ae3a-430c3a75e800@emailsignatures365.codetwo.com>
2023-03-08 15:43 ` Tony Hart
2023-03-10  0:08   ` Asaf Penso
2023-03-10  6:37     ` Jiawei(Jonny) Wang
2023-03-13  9:29       ` Tony Hart [this message]
2023-07-12  9:59         ` [External] " Maayan Kashani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E47A945E-3B8C-4BE8-9AB0-85863CC1E6EC@corero.com \
    --to=tony.hart@corero.com \
    --cc=asafp@nvidia.com \
    --cc=jiaweiw@nvidia.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).