On Thu, Aug 24, 2023 at 4:47 PM Mattias Rönnblom <hof...@lysator.liu.se> wrote: > > On 2023-08-22 14:32, Jerin Jacob wrote:
> >> Well, Eventdev does that already, except on systems where all required > >> event adapters have the appropriate INTERNAL_PORT capability. > > > > Yes. The difference is, one is for HW feature emulation and other one > > for framework usage. > > > > Can you elaborate why that difference is relevant? > > Both the adapters and the event dispatcher are optional, so if you have > an issue with service cores, you can avoid their use. Adaptor's service core is not optional if HW don't have that feature via adaptor API. > > > > 1)It is kind of enforcing above scheme for all the application > > modeling, which may not applicable for all application use cases and > > eventdev device does not dictate a specific framework model. > > > > What scheme is being enforced? Using this thing is optional. Yes. Exposing in rte_event_.... name space and framework is in lib/eventdev, one can think, it is layerd SW model and top most event dispatch needs to be used. Changing the namespace and move to different library will fix that problem. > > > 2) The framework code, we never kept in device class library. i.e., > > public APIs are implemented through device class API and public API > > don't have any no hook to PMD API. > > For example, we never kept lib/distributor/ code in lib/ethdev. > > > > I would to keep eventDEV library scope as abstracting event device features. > > We have some common code in library whose scope is sharing between PMDs > > not a framework on top eventdev public APIs. > > > > Having said that, I supportive to get this framework as new library and > > happy to review the new library. > > > > Thanks. > > I'll reshape the event dispatcher as a separate library and submit a new > patch. Ack > >> > >> I didn't review rte_graph in detail, but if it's anything like fd.io > >> VPP's graph model, it's not a programming model that you switch to > >> without significant application code impact. > > > > This is a new library, right? So, which existing applications? > > > > Existing DPDK applications, which domain logic is not organized as a > graph. Which, I'm guessing, are many. Yes. But I was comparing new application based on Graph vs new event dispatch model, not Graph vs "raw" event device. Nevertheless, if there are some in house application which is following event dispatch model and one wants to make that model as upstream as new library. No objections from my side. > > Moving from "raw" event device dequeue to the event dispatcher model is > a trivial, non-intrusive, operation. > > > It is not strictly like VPP graph model. rte_graph supports plugin for > > the different graph models. > > > > Following are the models available. > > https://doc.dpdk.org/guides/prog_guide/graph_lib.html > > See > > 62.4.5.1. RTC (Run-To-Completion) > > 62.4.5.2. Dispatch model > > > > RTC is similar to fd.io VPP. Other model is not like VPP. > > > > If we choose to take new library route instead of new rte_graph model > > for eventdev then > > https://doc.dpdk.org/guides/contributing/new_library.html will be the > > process.
