Event device early back-pressure indication

[Mattias Rönnblom]

On 2023-04-17 14:52, Jerin Jacob wrote:
> On Thu, Apr 13, 2023 at 12:24 PM Mattias Rönnblom
> <mattias.ronnblom at 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