> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Wednesday, September 20, 2023 3:02 PM > To: Naga Harish K, S V <s.v.naga.haris...@intel.com> > Cc: mattias.ronnblom <mattias.ronnb...@ericsson.com>; dev@dpdk.org; > Jerin Jacob <jer...@marvell.com>; techbo...@dpdk.org; Van Haaren, Harry > <harry.van.haa...@intel.com>; hof...@lysator.liu.se; Nilsson, Peter > <peter.j.nils...@ericsson.com>; Heng Wang <heng.w...@ericsson.com>; > Pavan Nikhilesh <pbhagavat...@marvell.com>; Gujjar, Abhinandan S > <abhinandan.guj...@intel.com>; Carrillo, Erik G <erik.g.carri...@intel.com>; > Shijith Thotton <sthot...@marvell.com>; Hemant Agrawal > <hemant.agra...@nxp.com>; Sachin Saxena <sachin.sax...@oss.nxp.com>; > Liang Ma <lian...@liangbit.com>; Mccarthy, Peter > <peter.mccar...@intel.com>; Yan, Zhirun <zhirun....@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.haris...@intel.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Mattias Rönnblom <mattias.ronnb...@ericsson.com> > > > Sent: Monday, September 4, 2023 6:33 PM > > > To: dev@dpdk.org > > > Cc: Jerin Jacob <jer...@marvell.com>; techbo...@dpdk.org; Van > > > Haaren, Harry <harry.van.haa...@intel.com>; hof...@lysator.liu.se; > > > Nilsson, Peter <peter.j.nils...@ericsson.com>; Heng Wang > > > <heng.w...@ericsson.com>; Naga Harish K, S V > > > <s.v.naga.haris...@intel.com>; Pavan Nikhilesh > > > <pbhagavat...@marvell.com>; Gujjar, Abhinandan S > > > <abhinandan.guj...@intel.com>; Carrillo, Erik G > > > <erik.g.carri...@intel.com>; Shijith Thotton <sthot...@marvell.com>; > > > Hemant Agrawal <hemant.agra...@nxp.com>; Sachin Saxena > > > <sachin.sax...@oss.nxp.com>; Liang Ma <lian...@liangbit.com>; > > > Mccarthy, Peter <peter.mccar...@intel.com>; Yan, Zhirun > > > <zhirun....@intel.com>; mattias.ronnblom > > > <mattias.ronnb...@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.ronnb...@ericsson.com> > > > Tested-by: Peter Nilsson <peter.j.nils...@ericsson.com> > > > Reviewed-by: Heng Wang <heng.w...@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. > Even if a HW comes(I assume not), the interface should not look like that. > None of the HW will be comparing a bunch of function pointers and call the > callback. > So interface will look different for HW enablement. We need to model the API > based on HW for device libraries and SW libraries based on CPU modeling > dynamics. > > Also, There is no need to tie up this library/framework only event ]dev, other > than using rte_event_dequeue() to pull packet it has no eventdev > significance. > The library scope if just pull the packet from a source and compare with in N > number of matches and call respective process callback. > The dispatcher source can rte_ethdev_rx_burst or ring. The current implementation of rte_dispatcher is event-dev centric. All the data structures are defined around the eventdev. The documentation also mentions it is for eventdev-based applications. Maybe the documentation needs to have the info on supporting different sources (from ethdev, ring etc).
