RE: [RFC] ethdev: add group set miss actions API

[Ori Kam <orika@nvidia.com>]

Hi Ivan and Tomer,

The RFC looks good to me, some comments inline.

> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Tuesday, August 8, 2023 7:15 PM
> 
> Hi Tomer,
> 
> OK, let's see what others will say.
> Minor comment below.
> 
> On Tue, 8 Aug 2023, Tomer Shmilovich wrote:
> 
> > Hi Ivan, please see inline comments.
> >
> > Thanks, Tomer
> >
> >> -----Original Message-----
> >> From: Ivan Malov <ivan.malov@arknetworks.am>
> >> Sent: Tuesday, 8 August 2023 2:03
> >> To: Tomer Shmilovich <tshmilovich@nvidia.com>
> >> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> >> (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@amd.com>;
> >> Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org
> >> Subject: Re: [RFC] ethdev: add group set miss actions API
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> Hi Tomer,
> >>
> >> This is a good proposal overall, but it's a bit questionable with regard to the
> >> transfer domain and precisely group 0.
> >>
> >> Say, the user starts a DPDK application and plugs a PF to it, also plugs a
> >> representor for a VF. If I'm not mistaken, in this case, default behaviour is
> >> hardly "undefined" for group 0. Packets sent by a VF are expected to reach
> the
> >> representor (and vice versa). Also, packets arriving on the physical port are
> >> expected to hit the PF port, ethdev 0, for instance.
> >>
> >
> > True.
> >
> >> Does this new API intend to re-define this? I mean, if the application fails to
> set
> >> the default action for group 0 (ENOTSUP), shall it assume that the behaviour
> >> will be as described above? And if it succeeds, then assume that such implicit
> >> interconnections cease functioning?
> >>
> >> So, this API is something like "isolated mode"
> >> in the case of non-transfer API, but allowing to choose a "default" action
> >> rather than DROP?
> >
> > You have a point. These are the default "miss actions" for all use cases as I
> understand them:
> > Transfer - miss group 0 - goes to the other side of the connection: rep --> VF,
> VF --> rep.
> > Transfer - miss group > 0 - goes to E-switch manager (proxy port).
> > Ingress - miss group 0 - goes to application when expected (i.e. promiscuous
> mode); otherwise drop/go to kernel in case of bifurcated driver.
> > Ingress - miss group > 0 - drop.
> > Egress - miss any group - goes to wire.
> >
> > I suggest documenting these default "miss actions", and have the new
> function update the miss actions for a given group.
> > If an application sets the group's miss actions as none (i.e. actions[0].type ==
> RTE_FLOW_ACTION_TYPE_END), the miss actions should be restored to the
> aforementioned default miss actions.
> 
> There is also an action "PASSTHRU". It can potentially be used with this
> meaning as "use implicit defaults", as "PASSTHRU" + "END".
> Or just "END", as you suggest. Perhaps others will
> take a look at this, too.
> 
> Thank you.
> 
According to my understanding "PASSTHRU" action
means that a packet after hitting a rule will continue in the same table trying to match lower priority/different rules.
"PASSTHRU" doesn't define what happens to flows that matched the first rule but didn't match
any other rule. 
Based on the above if we combine the two we can set all rules for example with the "PASSTHRU"
set the requested default action. This will result in all rules having the same terminating action.

Might be nice since using this you can change with one command all the terminating action for all flows.

Best,
Ori

[Snip]