From: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: "Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
"timothy.mcdaniel@intel.com" <timothy.mcdaniel@intel.com>,
"Hemant Agrawal" <hemant.agrawal@nxp.com>,
"Harry van Haaren" <harry.van.haaren@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Svante Järvstråt" <svante.jarvstrat@ericsson.com>,
"Heng Wang" <heng.wang@ericsson.com>,
"Stefan Sundkvist" <stefan.sundkvist@ericsson.com>,
"Peter Nilsson" <peter.nilsson@ericsson.com>,
"Maria Lingemark" <maria.lingemark@ericsson.com>
Subject: Re: Event device early back-pressure indication
Date: Mon, 17 Apr 2023 15:36:52 +0000 [thread overview]
Message-ID: <8f8db2f7-0d82-48fa-01b1-f5cadb0b57b3@ericsson.com> (raw)
In-Reply-To: <CALBAE1Mh6Dnro25dLiwEqsYU32e8_tLVxruat0DVyUcBSFdjug@mail.gmail.com>
On 2023-04-17 14:52, Jerin Jacob wrote:
> On Thu, Apr 13, 2023 at 12:24 PM Mattias Rönnblom
> <mattias.ronnblom@ericsson.com> wrote:
>>
>>
>> void
>> rte_event_return_new_credits(...);
>>
>> Thoughts?
>
> I see the following cons on this approach.
>
Does the use case in my original e-mail seem like a reasonable one to
you? If yes, is there some way one could solve this problem with a
clever use of the current Eventdev API? That would obviously be preferable.
> # Adding multiple APIs in fast path to driver layer may not
> performance effective solution.
For event devices with a software-managed credit system, pre-allocation
would be very cheap. And, if an application prefer to handle back
pressure after-the-fact, that option is still available.
> # At least for cnxk HW, credits are for device, not per port. So cnxk
> HW implementation can not use this scheme.
>
DSW's credit pool is also per device, but are cached on a per-port
basis. Does cnxk driver rely on the hardware to signal "new event" back
pressure? (From the driver code it looks like that is the case.)
> Alternative solution could be, adding new flag for
> rte_enqueue_new_burst(), where drivers waits until credit is available
> to reduce the application overhead > and support in different HW implementations if this use case critical.
>
> #define RTE_EVENT_FLAG_WAIT_TILL_CREDIT_AVILABLE (UINT32_C(1) << 0)
>
>
This solution only works if the event device is the only source of work
for the EAL thread. That is a really nice model, but I wouldn't trust on
that to always be the case.
Also, there may be work that should only be performed, if the system is
not under very high load. Credits being available, especially combined
with a flexible new even threshold would be an indicator.
Another way would be to just provide an API call that gave an indication
of a particular threshold has been reached (or simply return an
approximation of the number of in-flight events). Such a mechanism
wouldn't be able to leave any guarantees, but could make a future
enqueue operation very likely to succeed.
>>
>> Best regards,
>> Mattias
next prev parent reply other threads:[~2023-04-17 15:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 6:54 Mattias Rönnblom
2023-04-13 12:55 ` Heng Wang
2023-04-17 12:52 ` Jerin Jacob
2023-04-17 15:36 ` Mattias Rönnblom [this message]
2023-04-19 11:06 ` Jerin Jacob
2023-04-27 9:15 ` Mattias Rönnblom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f8db2f7-0d82-48fa-01b1-f5cadb0b57b3@ericsson.com \
--to=mattias.ronnblom@ericsson.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=heng.wang@ericsson.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=maria.lingemark@ericsson.com \
--cc=peter.nilsson@ericsson.com \
--cc=stefan.sundkvist@ericsson.com \
--cc=svante.jarvstrat@ericsson.com \
--cc=timothy.mcdaniel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).