On 2021-08-03 06:39, Jerin Jacob wrote:
On Mon, Aug 2, 2021 at 9:45 PM Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:Extend Eventdev API to allow for event devices which require various forms of internal processing to happen, even when events are not enqueued to or dequeued from a port. RFC v2: - Change rte_event_maintain() return type to be consistent with the documentation. - Remove unused typedef from eventdev_pmd.h. Signed-off-by: Mattias Rönnblom <mattias.ronnb...@ericsson.com> Tested-by: Richard Eklycke <richard.ekly...@ericsson.com> Tested-by: Liron Himi <lir...@marvell.com> --- lib/eventdev/rte_eventdev.h | 62 +++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) +/** + * Maintain an event device. + * + * This function is only relevant for event devices which has the + * RTE_EVENT_DEV_CAP_REQUIRES_MAINT flag set. Such devices requires + * the application to call rte_event_maintain() on a port during periods + * which it is neither enqueuing nor dequeuing events from this + * port. No port may be left unattended. + * + * An event device's rte_event_maintain() is a low overhead function. In + * situations when rte_event_maintain() must be called, the application + * should do so often.See rte_service_component_register() scheme, If a driver needs additional house keeping it can use DPDK's service core scheme to abstract different driver requirements.We may not need any public API for this.
What DSW requires, and indeed any event device that does software-level event buffering, is a way schedule the execution of some function to some time later, on the lcore that currently "owns" that port.
Put differently; it's not that the driver "needs some cycles at time T", but "it needs some cycles at time T on the lcore thread that currently is the user of eventdev port X".
The DSW output buffers and other per-port data structures aren't, for simplicity and performance, MT safe. That's one of the reasons the processing can't be done by a random service lcore.
Pushing output buffering into the application (or whatever is accessing the event device) is not a solution to the DSW<->adapter integration issue, since DSW also requires per-port deferred work for the flow migration machinery. In addition, if you have a look at the RX adapter, for example, you'll see that the buffering logic adds complexity to the "application".
The services cores are a rather course-grained deferred work construct. A more elaborate one might well have been the basis of a better solution than the proposed rte_event_maintain(), user-driven API.
rte_event_maintain() is a crude way to make the Ethernet/Crypto/Timer adapters work with DSW. I would argue it still puts us in a better position than we are today, where the DSW+adapter combo doesn't work at all.
If/when a more fancy DPDK deferred work framework comes along, rte_event_maintain() may be deprecated. Something like work queues in Linux could work, run as a DPDK service. In such a case, you might also need to require a service-cores-only deployment, and thus disallow the use of user-launched lcore threads.
That, however, is not a couple of tiny patches.
