Thread (22 messages) 22 messages, 4 authors, 2018-09-12

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 status

quoted
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 one
doesn’t care
quoted
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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help