>
> # Other than that, I am still not able to understand, why not
> application wait until rte_event_port_unlink() returns.
Making rte_event_port_unlink() blocking would be troublesome if one doesn’t care
about unlink completion. E.g. doing dynamic load balancing.
>
> # What in real word use case, application can, do other than waiting
> to complete rte_event_port_unlink(). If we try to put some logic in like,
>
> while (rte_event_port_unlink_in_progress(dev, port) > 0){
> do_something();
> }
>
> The do_something() will not be called in some platform at all.
>
> # Any idea on what will be the real world use case, where
> rte_event_port_unlink() called in fastpath?
In our application this could be used for example to pause scheduling of new
events while
working on an “expensive” event to minimise delays. It is also needed when
destroying
queues, though calling this fast path is debatable (our application enables
creating /
destroying queues at runtime).
These are perhaps not the best examples but I would be very cautious to make a
function
blocking if there is even a small probability that it could be called from the
fast path.
