On 02-Mar-18 6:51 PM, Stephen Hemminger wrote:
On Tue, 27 Feb 2018 14:59:29 +
Anatoly Burakov wrote:
This API is similar to the blocking API that is already present,
but reply will be received in a separate callback by the caller.
Under the hood, we create a separate thread to deal with r
On 02-Mar-18 6:48 PM, Stephen Hemminger wrote:
On Tue, 27 Feb 2018 14:59:29 +
Anatoly Burakov wrote:
+rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts)
{
+ struct sync_request *dummy;
+ struct async_request_shared_param *param = NULL;
+ struct rte_
On Tue, 27 Feb 2018 14:59:29 +
Anatoly Burakov wrote:
> This API is similar to the blocking API that is already present,
> but reply will be received in a separate callback by the caller.
>
> Under the hood, we create a separate thread to deal with replies to
> asynchronous requests, that wi
On Tue, 27 Feb 2018 14:59:29 +
Anatoly Burakov wrote:
> +rte_mp_request_async(struct rte_mp_msg *req, const struct timespec *ts)
> {
> + struct sync_request *dummy;
> + struct async_request_shared_param *param = NULL;
> + struct rte_mp_reply *reply = NULL;
> + int dir_fd, ret
On 27-Feb-18 2:59 PM, Anatoly Burakov wrote:
This API is similar to the blocking API that is already present,
but reply will be received in a separate callback by the caller.
Under the hood, we create a separate thread to deal with replies to
asynchronous requests, that will just wait to be noti
This API is similar to the blocking API that is already present,
but reply will be received in a separate callback by the caller.
Under the hood, we create a separate thread to deal with replies to
asynchronous requests, that will just wait to be notified by the
main thread, or woken up on a timer
6 matches
Mail list logo
