Re: eventdev: method for finding out unlink status
From: Jerin Jacob <hidden>
Date: 2018-08-10 17:35:21
-----Original Message-----
Date: Fri, 10 Aug 2018 16:55:31 +0000 From: "Van Haaren, Harry" <redacted> To: Jerin Jacob <redacted>, "Elo, Matias (Nokia - FI/Espoo)" [off-list ref] CC: "dev@dpdk.org" <redacted> Subject: RE: [dpdk-dev] eventdev: method for finding out unlink statusquoted
From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] Sent: Friday, August 10, 2018 3:52 PM To: Elo, Matias (Nokia - FI/Espoo) <redacted> Cc: Van Haaren, Harry <redacted>; dev@dpdk.org Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status -----Original Message-----quoted
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 onedoesn’t carequoted
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?I'm not sure I understand the issue here. Is anybody suggesting to make unlink() blocking? For certain PMDs, perhaps it must be a synchronous handled unlink(). For other PMDs (eg event/sw) there are multiple threads involved, so it must be async. Hence, APIs should be async to avoid blocking the caller. With an async API, if you don't want the async behaviuor, it is easy to build the sync version: call it in a loop, optionally with a delay().
Correct. My point was, rte_event_port_unlink() can be blocking as it is a slow path API(does not really matter how long it waits). If you think, it can be called in fastpath and/or application can leverage some cpu cycles on completing the async call then you can add at the cost of new API unlinks_in_progress() and make sure to update the documentation about unlink() that it can be async call(currently it is documented as a sync call).