[RFC 1/3] eventdev: introduce link profiles

[Jerin Jacob]

On Wed, Aug 9, 2023 at 7:56 PM <pbhagavatula at marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula at marvell.com>
>
> A collection of event queues linked to an event port can be
> associated with a unique identifier called as a profile, multiple
> such profiles can be created based on the event device capability
> using the function `rte_event_port_link_with_profile` which takes
> arguments similar to `rte_event_port_link` in addition to the profile
> identifier.
>
> The maximum link profiles that are supported by an event device
> is advertised through the structure member
> `rte_event_dev_info::max_profiles_per_port`.
> By default, event ports are configured to use the link profile 0
> on initialization.
>
> Once multiple link profiles are set up and the event device is started,
> the application can use the function `rte_event_port_change_profile`
> to change the currently active profile on an event port. This effects
> the next `rte_event_dequeue_burst` call, where the event queues
> associated with the newly active link profile will participate in
> scheduling.
>
> An unlink function `rte_event_port_unlink_with_profile` is provided
> to modify the links associated to a profile, and
> `rte_event_port_links_get_with_profile`can be used to retrieve the
> links associated with a profile.

in rte_flow APIs, similar concept is called as template.

I think "why" part is missing in the comment and programming guide.
i.e improving performance by creating template/profile in slow path
for faster link/unlink operation.

>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula at marvell.com>

Some suggestion on API name to have proper prefix and keeping verb as last.


rte_event_port_profile_link_set()
rte_event_port_profile_link_get()
rte_event_port_profile_unlink()
rte_event_port_profile_switch()


>

Please start with heading for this new block

> +An application can also use link profiles if supported by the underlying event device to setup up
> +multiple link profile per port and change them run time depending up on heuristic data.
> +
> +An Example use case could be as follows.
> +
> +Config path:
> +
> +.. code-block:: c
> +
> +        uint8_t lowQ[4] = {4, 5, 6, 7};
> +        uint8_t highQ[4] = {0, 1, 2, 3};

Please remove Hungarian notation.


> +
> +        if (rte_event_dev_info.max_profiles_per_port < 2)
> +            return -ENOTSUP;
> +
> +        rte_event_port_link_with_profile(0, 0, highQ, NULL, 4, 0);
> +        rte_event_port_link_with_profile(0, 0, lowQ, NULL, 4, 1);
> +
> +Worker path:
> +
> +.. code-block:: c
> +
> +        uint8_t empty_high_deq = 0;
> +        uint8_t empty_low_deq = 0;
> +        uint8_t is_low_deq = 0;
> +        while (1) {
> +            deq = rte_event_dequeue_burst(0, 0, &ev, 1, 0);

> +            if (deq == 0) {
> +                /**
> +                 * Change link profile based on work activity on current
> +                 * active profile
> +                 */
> +                if (is_low_deq) {
> +                    empty_low_deq++;
> +                    if (empty_low_deq == MAX_LOW_RETRY) {
> +                        rte_event_port_change_profile(0, 0, 0);
> +                        is_low_deq = 0;
> +                        empty_low_deq = 0;
> +                    }
> +                    continue;
> +                }
> +
> +                if (empty_high_deq == MAX_HIGH_RETRY) {
> +                    rte_event_port_change_profile(0, 0, 1);
> +                    is_low_deq = 1;
> +                    empty_high_deq = 0;
> +                }
> +                continue;
> +            }
> +
> +            // Process the event received.
> +
> +            if (is_low_deq++ == MAX_LOW_EVENTS) {
> +                rte_event_port_change_profile(0, 0, 0);
> +                is_low_deq = 0;
> +            }
> +        }


As far programming document is concerned, we don't need to put such
complicated logic here.
We can put some comments something like “Find the profile ID to switch”

uint8_t profile_id_to_switch = app_find_profile_id_to_switch();
rte_event_port_profile_switch(.., profile_id_to_switch );


>
> diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
> index 60c5cd4804..580057870f 100644
> --- a/drivers/event/dlb2/dlb2.c
> +++ b/drivers/event/dlb2/dlb2.c
> @@ -79,6 +79,7 @@ static struct rte_event_dev_info evdev_dlb2_default_info = {
>                           RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
>                           RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
>                           RTE_EVENT_DEV_CAP_MAINTENANCE_FREE),
> +       .max_profiles_per_port = 1,
>  };
>
>  struct process_local_port_data
> diff --git a/drivers/event/dpaa/dpaa_eventdev.c b/drivers/event/dpaa/dpaa_eventdev.c
> index 4b3d16735b..f615da3813 100644
> --- a/drivers/event/dpaa/dpaa_eventdev.c
> +++ b/drivers/event/dpaa/dpaa_eventdev.c
> @@ -359,6 +359,7 @@ dpaa_event_dev_info_get(struct rte_eventdev *dev,
>                 RTE_EVENT_DEV_CAP_NONSEQ_MODE |
>                 RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
>                 RTE_EVENT_DEV_CAP_MAINTENANCE_FREE;

We are always adding CAPA for new eventdev features. Please add
RTE_EVENT_DEV_CAPA_PROFILE_LINK or so.

> @@ -131,6 +131,11 @@ EXPERIMENTAL {
>         rte_event_eth_tx_adapter_runtime_params_init;
>         rte_event_eth_tx_adapter_runtime_params_set;
>         rte_event_timer_remaining_ticks_get;
> +
> +       # added in 23.11
> +       rte_event_port_link_with_profile;
> +       rte_event_port_unlink_with_profile;
> +       rte_event_port_links_get_with_profile;

Missed the API to switch the profile.

>  };
>
>  INTERNAL {
> --
> 2.25.1
>