> -----Original Message----- > From: Pavan Nikhilesh Bhagavatula <[email protected]> > Sent: Thursday, July 14, 2022 5:42 PM > To: mattias.ronnblom <[email protected]>; Thomas Monjalon > <[email protected]> > Cc: Jerin Jacob Kollanukkaran <[email protected]>; Ray Kinsella > <[email protected]>; > [email protected]; McDaniel, Timothy <[email protected]>; Hemant > Agrawal <[email protected]>; [email protected]; > [email protected]; Mccarthy, Peter <[email protected]>; Van Haaren, > Harry <[email protected]>; Carrillo, Erik G > <[email protected]>; > Gujjar, Abhinandan S <[email protected]>; Jayatheerthan, Jay > <[email protected]>; Burakov, Anatoly <[email protected]> > Subject: RE: [EXT] Re: [PATCH 1/2] doc: add enqueue depth for new event type
<snip old conversation> > > >> If the underlying hardware has some limitations, > > >> why not let the driver loop until back pressure occurs? Then you can > > > > You didn't answer this question. Why not let the driver loop, until you > > for some reason or the other can't accept more events? > > CNXK event driver cannot accept forwarding(enq) more than one event that has > been dequeued. Enqueueing more than one event for forwarding/releasing > is a violation from HW perspective, this is currently announced by BURST > capability. > But It can enqueue a burst if new events. Can't the driver just backpressure NEW events? that's what the event/sw driver does in order to limit "new" inflight events. App attempts to enq FWD/REL, no problem. App enqueues burst of NEW (and there's only N spaces) then the first N events pass, and the rest are returned to the application. > If you see the current example implementation we pick the worker based on > BURST capability for optimizing the enqueue/dequeue by providing a hint > to the driver layer. Please provide a link to the code? Others are not familiar with the CNXK driver, or the sample code you're referring to... > Although, we could live with aggregating the events at driver layer based on > queue. We would still require announce burst capability for new events i.e. > changes to the info structure. As per above, I still don't see a reason why this HW optimization/limitation needs to be pushed to the application layer. Why can the driver not handle things by allowing/backpressure to the events it can/can't handle? In this email thread[1] you've suggested reworking the rx_burst API with a flag to indicate "same destination". This still pushes the problem to the application, and exposes more HW/PMD specific options. This impl is *slightly* better because it wont' require new APIs for each mode, but also *breaks all existing apps*!? I'm just not understanding why the application needs to change, and why it cannot be optimized/handled in the driver layer. [1] http://mails.dpdk.org/archives/dev/2022-July/246717.html <snip old conversation>
