[PATCH v3 1/3] lib: introduce dispatcher library

[Jerin Jacob]

On Thu, Sep 21, 2023 at 11:29 AM Naga Harish K, S V
<s.v.naga.harish.k at intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk at gmail.com>
> > Sent: Wednesday, September 20, 2023 3:02 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k at intel.com>
> > Cc: mattias.ronnblom <mattias.ronnblom at ericsson.com>; dev at dpdk.org;
> > Jerin Jacob <jerinj at marvell.com>; techboard at dpdk.org; Van Haaren, Harry
> > <harry.van.haaren at intel.com>; hofors at lysator.liu.se; Nilsson, Peter
> > <peter.j.nilsson at ericsson.com>; Heng Wang <heng.wang at ericsson.com>;
> > Pavan Nikhilesh <pbhagavatula at marvell.com>; Gujjar, Abhinandan S
> > <abhinandan.gujjar at intel.com>; Carrillo, Erik G <erik.g.carrillo at intel.com>;
> > Shijith Thotton <sthotton at marvell.com>; Hemant Agrawal
> > <hemant.agrawal at nxp.com>; Sachin Saxena <sachin.saxena at oss.nxp.com>;
> > Liang Ma <liangma at liangbit.com>; Mccarthy, Peter
> > <peter.mccarthy at intel.com>; Yan, Zhirun <zhirun.yan at intel.com>
> > Subject: Re: [PATCH v3 1/3] lib: introduce dispatcher library
> >
> > On Mon, Sep 18, 2023 at 5:26 AM Naga Harish K, S V
> > <s.v.naga.harish.k at intel.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Mattias Rönnblom <mattias.ronnblom at ericsson.com>
> > > > Sent: Monday, September 4, 2023 6:33 PM
> > > > To: dev at dpdk.org
> > > > Cc: Jerin Jacob <jerinj at marvell.com>; techboard at dpdk.org; Van
> > > > Haaren, Harry <harry.van.haaren at intel.com>; hofors at lysator.liu.se;
> > > > Nilsson, Peter <peter.j.nilsson at ericsson.com>; Heng Wang
> > > > <heng.wang at ericsson.com>; Naga Harish K, S V
> > > > <s.v.naga.harish.k at intel.com>; Pavan Nikhilesh
> > > > <pbhagavatula at marvell.com>; Gujjar, Abhinandan S
> > > > <abhinandan.gujjar at intel.com>; Carrillo, Erik G
> > > > <Erik.G.Carrillo at intel.com>; Shijith Thotton <sthotton at marvell.com>;
> > > > Hemant Agrawal <hemant.agrawal at nxp.com>; Sachin Saxena
> > > > <sachin.saxena at oss.nxp.com>; Liang Ma <liangma at liangbit.com>;
> > > > Mccarthy, Peter <Peter.Mccarthy at intel.com>; Yan, Zhirun
> > > > <Zhirun.Yan at intel.com>; mattias.ronnblom
> > > > <mattias.ronnblom at ericsson.com>
> > > > Subject: [PATCH v3 1/3] lib: introduce dispatcher library
> > > >
> > > > The purpose of the dispatcher library is to help reduce coupling in
> > > > an Eventdev-based DPDK application.
> > > >
> > > > In addition, the dispatcher also provides a convenient and flexible
> > > > way for the application to use service cores for application-level processing.
> > > >
> > > > Signed-off-by: Mattias Rönnblom <mattias.ronnblom at ericsson.com>
> > > > Tested-by: Peter Nilsson <peter.j.nilsson at ericsson.com>
> > > > Reviewed-by: Heng Wang <heng.wang at ericsson.com>
> > > >
> > > > --
> > > >
> > > > PATCH v3:
> > > >  o To underline its optional character and since it does not provide
> > > >    hardware abstraction, the event dispatcher is now a separate
> > > >    library.
> > > >  o Change name from rte_event_dispatcher -> rte_dispatcher, to make it
> > > >    shorter and to avoid the rte_event_* namespace.
> > > >
> > >
> > > Rte_dispatcher is basically dispatching events but it feels like the name does
> > not convey that.
> > > Also, it is like any other adapter service that can reside within the eventdev
> > directory.
> > >
> > > I can see some discussion in previous threads related to the placement of the
> > dispatcher library.
> > >
> > > It is an optional eventdev application service, not enforcing this
> > programming model to the application.
> > > The documentation may need to be updated and mention that this is
> > optional.
> > >
> > > If any hardware comes up with the dispatcher feature, then this library may
> > need to be moved inside eventdev library later.
> >
> > I would like to follow YAGNI principle in eventdev library.
>
> What is YAGNI principle? for understanding purposes.

https://www.techtarget.com/whatis/definition/You-arent-gonna-need-it#:~:text=YAGNI%20principle%20(%22You%20Aren',desired%20increased%20frequency%20of%20releases.

What meant by that, If it meant to be abstracting any HW Device
feature(on the point of above: If any hardware comes up with the
dispatcher feature, then this library may
need to be moved inside eventdev library later) lest define API based
on a Device definition and its capability. If it is targeting for an
SW library align API based on that.

For example, If this needed to be implemented in HW as device feature,
I would implement as following
- CAM as ACL or EM to store the rules
- Key extractor to extract the interested filed(match actions).
Similar to rte_flow flow patterns
- Action will something similar to rte_flow mark action
(https://doc.dpdk.org/guides/prog_guide/rte_flow.html#action-mark).
- When packet/event delivered to application. HW stores the mark value
in the metadata up on match.

For such HW, if we try to abstract with current API proposal, it is
not efficient.
On the other way, if the use case, addressing the existing SW API
library and model around the above HW primitives also not efficient.