On 2019-12-06 17:32, Venky Venkatesh wrote:
Thanks Mattias for the clarifications.
1 more question: This time it is about the inflight accounting for DSW.
Here is my understanding: it seems to consider only the events which
are *inside
the scheduler* as in flight.
Yes, like all event devices, I believe.
I am trying to distinguish it from those which
have been currently given to cores by the scheduler. The latter are not
considered in flight since we dsw_port_return_credits as soon as
dsw_event_dequeue_burst.
A new dequeue means an implicit release of all unreleased events
dequeued in the previous call. It's standard Eventdev semantics.
So if these events which are in core currently do
a FORWARD, there is a chance that those can fail. Ideally those FORWARDs
should not fail -- which can happen with the current design as some NEWs
can hog those credits freed up by the ones which have been dequeued by
cores.
What you do to avoid this situation is set the new_event_threshold
low-enough, so NEW events don't block FORWARDed ones.
Is this design of DSW intentional or an omission? If it is an
omission I can work on a possible fix and run it by you.
This is not really a DSW design, but rather how Eventdev works.
