> -----Original Message----- > From: Jerin Jacob <[email protected]> > Sent: Wednesday, September 20, 2023 3:02 PM > To: Naga Harish K, S V <[email protected]> > Cc: mattias.ronnblom <[email protected]>; [email protected]; > Jerin Jacob <[email protected]>; [email protected]; Van Haaren, Harry > <[email protected]>; [email protected]; Nilsson, Peter > <[email protected]>; Heng Wang <[email protected]>; > Pavan Nikhilesh <[email protected]>; Gujjar, Abhinandan S > <[email protected]>; Carrillo, Erik G <[email protected]>; > Shijith Thotton <[email protected]>; Hemant Agrawal > <[email protected]>; Sachin Saxena <[email protected]>; > Liang Ma <[email protected]>; Mccarthy, Peter > <[email protected]>; Yan, Zhirun <[email protected]> > Subject: Re: [PATCH v3 1/3] lib: introduce dispatcher library > > On Mon, Sep 18, 2023 at 5:26 AM Naga Harish K, S V > <[email protected]> wrote: > > > > > > > > > -----Original Message----- > > > From: Mattias Rönnblom <[email protected]> > > > Sent: Monday, September 4, 2023 6:33 PM > > > To: [email protected] > > > Cc: Jerin Jacob <[email protected]>; [email protected]; Van > > > Haaren, Harry <[email protected]>; [email protected]; > > > Nilsson, Peter <[email protected]>; Heng Wang > > > <[email protected]>; Naga Harish K, S V > > > <[email protected]>; Pavan Nikhilesh > > > <[email protected]>; Gujjar, Abhinandan S > > > <[email protected]>; Carrillo, Erik G > > > <[email protected]>; Shijith Thotton <[email protected]>; > > > Hemant Agrawal <[email protected]>; Sachin Saxena > > > <[email protected]>; Liang Ma <[email protected]>; > > > Mccarthy, Peter <[email protected]>; Yan, Zhirun > > > <[email protected]>; mattias.ronnblom > > > <[email protected]> > > > 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 <[email protected]> > > > Tested-by: Peter Nilsson <[email protected]> > > > Reviewed-by: Heng Wang <[email protected]> > > > > > > -- > > > > > > 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).
