-----Original Message-----

Date: Fri, 10 Aug 2018 14:24:02 +0000
From: "Elo, Matias (Nokia - FI/Espoo)" <redacted>
To: Jerin Jacob <redacted>
CC: "Van Haaren, Harry" <redacted>, "dev@dpdk.org"
 [off-list ref]
Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
x-mailer: Apple Mail (2.3445.9.1)

quoted

# 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.

By making it as blocking(i.e the rte_event_port_unlink() returns when
unlink() completed) forcing everyone to care about unlink completion.
Right?

quoted

# 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).

If I understand it correctly, Your current issue is, SW driver is
not waiting for to complete the unlink() operation so that in your application you are
seeing some abnormalities.

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.

Let assume even if it is called in fastpath, what else, we can really do
other that calling rte_pause() in loop. realistically? after issuing
unlink() operation.