Re: [PATCH 1/3] lib: dpdk spec to skip red for ingress policer

[Jerin Jacob <jerinjacobk@gmail.com>]

On Thu, Jan 26, 2023 at 8:43 PM Ori Kam <orika@nvidia.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Rakesh Kudurumalla <rkudurumalla@marvell.com>
> > Sent: Wednesday, 18 January 2023 10:10
> >
> >
> > > -----Original Message-----
> > > From: Rakesh Kudurumalla
> > > Sent: Tuesday, January 10, 2023 12:12 PM
> > > To: Ori Kam <orika@nvidia.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> > > Stephen Hemminger <stephen@networkplumber.org>
> > > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; NBU-Contact-Adrien
> > > Mazarguil (EXTERNAL) <adrien.mazarguil@6wind.com>
> > > Subject: RE: [PATCH 1/3] lib: dpdk spec to skip red for ingress policer
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ori Kam <orika@nvidia.com>
> > > > Sent: Monday, December 26, 2022 10:30 PM
> > > > To: Jerin Jacob <jerinjacobk@gmail.com>; Stephen Hemminger
> > > > <stephen@networkplumber.org>
> > > > Cc: Rakesh Kudurumalla <rkudurumalla@marvell.com>; NBU-Contact-
> > > Thomas
> > > > Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; NBU-Contact-
> > Adrien
> > > > Mazarguil (EXTERNAL) <adrien.mazarguil@6wind.com>
> > > > Subject: [EXT] RE: [PATCH 1/3] lib: dpdk spec to skip red for ingress
> > > > policer
> > > >
> > > > External Email
> > > >
> > > > ----------------------------------------------------------------------
> > > > Hi All,
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Thursday, 22 December 2022 7:27
> > > > >
> > > > > On Thu, Dec 22, 2022 at 8:32 AM Stephen Hemminger
> > > > > <stephen@networkplumber.org> wrote:
> > > > > >
> > > > > > On Thu, 22 Dec 2022 07:09:02 +0530 Rakesh Kudurumalla
> > > > > > <rkudurumalla@marvell.com> wrote:
> > > > > >
> > > > > > > Dropping of packets based on RED can be skipped with meter
> > > > > > > action, when RED is configured using
> > > > > > > rte_eth_cman_config_set()
> > > > > > >
> > > > > > > Signed-off-by: Rakesh Kudurumalla <rkudurumalla@marvell.com>
> > > > > >
> > > > > > Should this be more general and apply to all congestion management
> > > > > > options. Assuming the hardware can do something better than RED.
> > > > >
> > > > > Yes. We can use "enum rte_cman_mode mode" in the descriptor to
> > > > > future- proof.
> > > >
> > > > I'm missing the idea of this new action, I understand that is related
> > > > to Jerin congestion patches.
> > > > But I fail to see why we need it? Is it to mark some metadata that
> > > > will have some effect on the congestion result? (I assume the system
> > > > is implemented in the HW)
> > >
> > > Yes. It is implemented in HW. Congestion management is applied on
> > ethdev
> > > Rx queue using rte_eth_cman_config() API. Once it is configured, it applies
> > to
> > > all the packets that steer towards that particular ethdev Rx queue. This
> > > feature help to skip the congestion management processing based on the
> > > packet color identified by the rte_flow meter object. For example, If one
> > Rx
> > > queue configured as RED congestion  and application wants to bypass the
> > > RED congestion  processing for all GREEN color packet can be expressed
> > > though this API proposal.
> >
> > Hi Ori Kam,
> >
> > Let me know if above information  would give clear idea on skip RED action
>
> I think so, to put it in my own words,  when setting this the selected packet is treated as
> green packet?
>
> If so, can we use the meter_color field? If you want the packet to be green just set the
> field to green?

It is already there in one form. See following in existing header file.

/**
 * Meter policy
 */
struct rte_mtr_meter_policy_params {
        /**
         * Policy action list per color.
         * actions[i] potentially represents a chain of rte_flow actions
         * terminated by the END action, exactly as specified by the rte_flow
         * API for the flow definition, and not just a single action.
         */
        const struct rte_flow_action *actions[RTE_COLORS];
};


>
> Best,
> Ori
>