> -----Original Message----- > From: Mattias Rönnblom <mattias.ronnb...@ericsson.com> > Sent: Wednesday, July 13, 2022 2:39 PM > To: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com>; Thomas > Monjalon <tho...@monjalon.net> > Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Ray Kinsella > <m...@ashroe.eu>; dev@dpdk.org; timothy.mcdan...@intel.com; Hemant > Agrawal <hemant.agra...@nxp.com>; sachin.sax...@oss.nxp.com; > lian...@liangbit.com; peter.mccar...@intel.com; > harry.van.haa...@intel.com; erik.g.carri...@intel.com; > abhinandan.guj...@intel.com; jay.jayatheert...@intel.com; > anatoly.bura...@intel.com > Subject: Re: [EXT] Re: [PATCH 1/2] doc: add enqueue depth for new event > type > > On 2022-07-12 20:11, Pavan Nikhilesh Bhagavatula wrote: > > +Cc > > timothy.mcdan...@intel.com; > > hemant.agra...@nxp.com; > > sachin.sax...@oss.nxp.com; > > mattias.ronnb...@ericsson.com; > > jer...@marvell.com; > > lian...@liangbit.com; > > peter.mccar...@intel.com; > > harry.van.haa...@intel.com; > > erik.g.carri...@intel.com; > > abhinandan.guj...@intel.com; > > jay.jayatheert...@intel.com; > > m...@ashroe.eu; > > anatoly.bura...@intel.com; > > > > > >> -----Original Message----- > >> From: Thomas Monjalon <tho...@monjalon.net> > >> Sent: Tuesday, July 12, 2022 8:31 PM > >> To: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com> > >> Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Ray Kinsella > >> <m...@ashroe.eu>; dev@dpdk.org; Pavan Nikhilesh Bhagavatula > >> <pbhagavat...@marvell.com> > >> Subject: [EXT] Re: [PATCH 1/2] doc: add enqueue depth for new event > type > >> > >> External Email > >> > >> ---------------------------------------------------------------------- > >> I'm not your teacher, but please consider Cc'ing people outside of your > >> company. > >> > > > > I generally add --to-cmd=./devtools/get-maintainer.sh but looks like it's > useless for > > sending deprecation notices. > > > > Maybe we should update it to include lib/driver maintainers when diff sees > deprecation.rst > > > >> > >> 27/06/2022 11:57, pbhagavat...@marvell.com: > >>> From: Pavan Nikhilesh <pbhagavat...@marvell.com> > >>> > >>> A new field ``max_event_port_enqueue_new_burst`` will be added to > the > >>> structure ``rte_event_dev_info``. The field defines the max enqueue > >>> burst size of new events (OP_NEW) supported by the underlying event > >>> device. > >>> > >>> Signed-off-by: Pavan Nikhilesh <pbhagavat...@marvell.com> > >>> --- > >>> doc/guides/rel_notes/deprecation.rst | 5 +++++ > >>> 1 file changed, 5 insertions(+) > >>> > >>> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >>> index 4e5b23c53d..071317e8e3 100644 > >>> --- a/doc/guides/rel_notes/deprecation.rst > >>> +++ b/doc/guides/rel_notes/deprecation.rst > >>> @@ -125,3 +125,8 @@ Deprecation Notices > >>> applications should be updated to use the ``dmadev`` library instead, > >>> with the underlying HW-functionality being provided by the ``ioat`` or > >>> ``idxd`` dma drivers > >>> + > >>> +* eventdev: The structure ``rte_event_dev_info`` will be extended to > >> include the > >>> + max enqueue burst size of new events supported by the underlying > >> event device. > >>> + A new field ``max_event_port_enqueue_new_burst`` will be added > to > >> the structure > >>> + ``rte_event_dev_info`` in DPDK 22.11. > >>> > >> > >> > >> > >> > > Why is this needed, or useful? Why isn't called something with > "enqueue_depth" in it, like the already-present field? >
This is for a case where enqueues with OP_FORWARD/OP_RELEASE only supports enqueue depth of 1. Where as OP_NEW supports higher burst size. This is already tied into capability description : #define RTE_EVENT_DEV_CAP_BURST_MODE (1ULL << 4) /**< Event device is capable of operating in burst mode for enqueue(forward, * release) and dequeue operation. If this capability is not set, application * still uses the rte_event_dequeue_burst() and rte_event_enqueue_burst() but * PMD accepts only one event at a time. * * @see rte_event_dequeue_burst() rte_event_enqueue_burst() */ > I think I would rather remove all fields related to the max > enqueue/dequeue burst sizes. They serve no purpose, as far as I see. If > you have some HW limit on the maximum number of new events it can > accept, have the driver retry until backpressure occurs.
