On 6/26/20 2:10 PM, Jerin Jacob wrote: > On Fri, Jun 26, 2020 at 4:16 PM Thomas Monjalon <tho...@monjalon.net> wrote: >> >> 26/06/2020 12:35, Jerin Jacob: >>> 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. >> >> 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. > > Not clear to me. I will wait for another explanation if any. > In what basics application set .1 vs .8? > >> >>> 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. > > +1 from me.
+1 > it is taking too much effort and time to make support duplicate APIs. > >> I want to help deprecating such API in 20.11 if possible. > > Please start that discussion. In this case, it is clear API overlap > with rte_eth_mirror_rule_set(). > We should not have two separate paths for the same function in the > same ethdev library. > > > >> >>>> Full mirroring is sampling 100% packets (ratio = 1). >>>> That's why only one action is enough. >> >> >>
