Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow

[Thomas Monjalon <thomas@monjalon.net>]

26/06/2020 12:35, Jerin Jacob:
> On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 25/06/2020 19:55, Jerin Jacob:
> > > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang <jiaweiw@mellanox.com> 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.