On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon <tho...@monjalon.net> wrote: > > 25/06/2020 19:55, Jerin Jacob: > > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang <jiaw...@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. 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? 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. > Full mirroring is sampling 100% packets (ratio = 1). > That's why only one action is enough. > >
