From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id BDE1C374E for ; Wed, 13 Mar 2019 16:42:44 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F31F87DCE6; Wed, 13 Mar 2019 15:42:43 +0000 (UTC) Received: from [10.36.112.54] (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7B67E27CC6; Wed, 13 Mar 2019 15:42:42 +0000 (UTC) To: Ilya Maximets , dev@dpdk.org, changpeng.liu@intel.com, tiwei.bie@intel.com, dariusz.stojaczyk@intel.com References: <20190312145410.570-1-maxime.coquelin@redhat.com> <20190312145410.570-3-maxime.coquelin@redhat.com> From: Maxime Coquelin Message-ID: <8fc721a3-b37d-a5fa-db1f-32e14453ce61@redhat.com> Date: Wed, 13 Mar 2019 16:42:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Mar 2019 15:42:44 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 2/2] vhost: support requests only handled by external backend X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:42:45 -0000 On 3/12/19 5:14 PM, Ilya Maximets wrote: > On 12.03.2019 17:54, Maxime Coquelin wrote: >> External backends may have specific requests to handle, and so >> we don't want the vhost-user lib to handle these requests as >> errors. >> >> This patch also changes the experimental API by introducing >> RTE_VHOST_MSG_RESULT_NOT_HANDLED so that vhost-user lib >> can report an error if a message is handled neither by >> the vhost-user library nor by the external backend. >> >> The logic changes a bit so that if the callback returns >> with ERR, OK or REPLY, it is considered the message >> is handled by the external backend so it won't be >> handled by the vhost-user library. >> It is still possible for an external backend to listen >> to requests that have to be handled by the vhost-user >> library like SET_MEM_TABLE, but the callback have to >> return NOT_HANDLED in that case. >> >> Vhost-crypto backend is ialso adapted to this API change. >> >> Suggested-by: Ilya Maximets >> Signed-off-by: Maxime Coquelin >> Tested-by: Darek Stojaczyk >> --- >> lib/librte_vhost/rte_vhost.h | 16 +++++-- >> lib/librte_vhost/vhost_crypto.c | 10 +++- >> lib/librte_vhost/vhost_user.c | 82 +++++++++++++++++++++------------ >> 3 files changed, 71 insertions(+), 37 deletions(-) >> >> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h >> index c9c392975..b1c5a0908 100644 >> --- a/lib/librte_vhost/rte_vhost.h >> +++ b/lib/librte_vhost/rte_vhost.h >> @@ -121,6 +121,8 @@ enum rte_vhost_msg_result { >> RTE_VHOST_MSG_RESULT_OK = 0, >> /* Message handling successful and reply prepared */ >> RTE_VHOST_MSG_RESULT_REPLY = 1, >> + /* Message not handled */ >> + RTE_VHOST_MSG_RESULT_NOT_HANDLED, >> }; >> >> /** >> @@ -135,11 +137,13 @@ enum rte_vhost_msg_result { >> * If the handler requires skipping the master message handling, this variable >> * shall be written 1, otherwise 0. > > Above statement should be updated because 'skip_master' removed. Right. > BTW, maybe it's better to squash these two typedef's as they are > equal now? Comment parts that differs could be moved to the definition > of the 'struct rte_vhost_user_extern_ops'. Good idea, doing it now. >> * @return >> - * VH_RESULT_OK on success, VH_RESULT_REPLY on success with reply, >> - * VH_RESULT_ERR on failure >> + * RTE_VHOST_MSG_RESULT_OK on success, >> + * RTE_VHOST_MSG_RESULT_REPLY on success with reply, >> + * RTE_VHOST_MSG_RESULT_ERR on failure, >> + * RTE_VHOST_MSG_RESULT_NOT_HANDLED if message was not handled. >> */ >> typedef enum rte_vhost_msg_result (*rte_vhost_msg_pre_handle)(int vid, >> - void *msg, uint32_t *skip_master); >> + void *msg); >> Thanks, Maxime