From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id EAF605699 for ; Wed, 27 Feb 2019 14:16:02 +0100 (CET) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20190227131601euoutp0171277dd3bba0a61422675a1f8c2a1742~HOudCZAcD1943319433euoutp01d for ; Wed, 27 Feb 2019 13:16:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20190227131601euoutp0171277dd3bba0a61422675a1f8c2a1742~HOudCZAcD1943319433euoutp01d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1551273361; bh=ek/EThCm9peI1jkqX/9e9q8ZZMNdn4j9zzJlELOQ/ow=; h=Subject:To:From:Date:In-Reply-To:References:From; b=kmym4sqMJo7ufqPA3x8/nqp4LmkNUTngUJ693YOHvh4cJ5qHuEmzP1d1QZ7Be3CIl DMLunXPMxPY3a1x4jW/SUap+zl80udi2k5VgqcWhkbWEgJdJip+VjlGdM34qXR+8CD hrqaW75jd8B8JTSzlTUaFql37m3LSmdOs6QwK0JY= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20190227131601eucas1p2ffd509533d739688f766aa87645b80f2~HOucnrSa40536105361eucas1p2b; Wed, 27 Feb 2019 13:16:01 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 5A.B0.04294.09D867C5; Wed, 27 Feb 2019 13:16:00 +0000 (GMT) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20190227131600eucas1p2a00cfc335786583e739b549634499a40~HOubk-B1m0978209782eucas1p2H; Wed, 27 Feb 2019 13:16:00 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20190227131559eusmtrp1cc6ae45c22074899daaf674e22212d4e~HOubWok-f1404214042eusmtrp1K; Wed, 27 Feb 2019 13:15:59 +0000 (GMT) X-AuditID: cbfec7f4-835ff700000010c6-32-5c768d900a4a Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 4B.3A.04284.F8D867C5; Wed, 27 Feb 2019 13:15:59 +0000 (GMT) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20190227131559eusmtip1d91e0527e2a35aae7265957ed2d36188~HOua_qQwo2002120021eusmtip1b; Wed, 27 Feb 2019 13:15:59 +0000 (GMT) To: Maxime Coquelin , dev@dpdk.org, changpeng.liu@intel.com, tiwei.bie@intel.com From: Ilya Maximets Message-ID: Date: Wed, 27 Feb 2019 16:15:58 +0300 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: <20190227100235.14514-3-maxime.coquelin@redhat.com> Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsWy7djPc7oTestiDL53q1pc/PmV3eLdp+1M Flfaf7JbHOvcw2KxteE/kwOrx68FS1k9Fu95yeTxft9VNo++LasYA1iiuGxSUnMyy1KL9O0S uDJad3awFtyVrlh+eD5LA2O7WBcjJ4eEgInE+13XWbsYuTiEBFYwSvxefJEZwvnCKDGp7Qwb hPOZUWLfkp2MXYwcYC1zjvNDxJczSsxvXMkIMkpI4COjxM7nKiC2sEC0RPvbu0wgtohAnsTc U6fAbDYBHYlTq4+A1fMK2El0dbSxgNgsAqoSvZMvs4HYogIREu+f7maBqBGUODnzCZjNKeAg se37JbBeZgFxiaYvK1khbHmJ7W/ngF0tIdDPLjGt/TI7xG8uEp+bP0DZwhKvjm+BsmUkTk/u YYGw6yXut7xkhGjuYJSYfugfE0TCXmLL63PsIB8zC2hKrN+lD/G8o8TEg/YQJp/EjbeCECfw SUzaNp0ZIswr0dEmBDFDReL3weXMELaUxM13n6EO8JBYd3A24wRGxVlInpyF5LFZSB6bhXDC AkaWVYziqaXFuempxUZ5qeV6xYm5xaV56XrJ+bmbGIEp5vS/4192MO76k3SIUYCDUYmHV6On LEaINbGsuDL3EKMEB7OSCG9vEVCINyWxsiq1KD++qDQntfgQozQHi5I4bzXDg2ghgfTEktTs 1NSC1CKYLBMHp1QDo/WZP+stbQwlddMz2eoXX302P2Hl44Kof4uXVl7Su3irTeD60ijFsNuZ +eords6rDVWYYvXw6TYD6YfZM7ZrZ2lIrpJe/MpRYsFfU4kd7i4KmvHxjlWP3p+97/ninoHH Qy/eyIDjzo/kT5ZYyysnL6/6ks7xylD8wpRH67xnnzTakJk2v97irRJLcUaioRZzUXEiAIpT rHEtAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsVy+t/xu7r9vWUxBgsfa1tc/PmV3eLdp+1M Flfaf7JbHOvcw2KxteE/kwOrx68FS1k9Fu95yeTxft9VNo++LasYA1ii9GyK8ktLUhUy8otL bJWiDS2M9AwtLfSMTCz1DI3NY62MTJX07WxSUnMyy1KL9O0S9DJad3awFtyVrlh+eD5LA2O7 WBcjB4eEgInEnOP8XYxcHEICSxklOo/eZexi5ASKS0n8+HWBFcIWlvhzrYsNxBYSeM8osWyf OYgtLBAt0f72LhOILSKQJ3Hs9hNmiEEnGSV2vlwM1swmoCNxavURsKG8AnYSXR1tLCA2i4Cq RO/ky2BDRQUiJO5efMECUSMocXLmEzCbU8BBYtv3S2C9zALqEn/mXWKGsMUlmr6sZIWw5SW2 v53DPIFRcBaS9llIWmYhaZmFpGUBI8sqRpHU0uLc9NxiQ73ixNzi0rx0veT83E2MwPjZduzn 5h2MlzYGH2IU4GBU4uHV6CmLEWJNLCuuzD3EKMHBrCTC21sEFOJNSaysSi3Kjy8qzUktPsRo CvTcRGYp0eR8YGznlcQbmhqaW1gamhubG5tZKInznjeojBISSE8sSc1OTS1ILYLpY+LglGpg FPwQ89u/Q38nv8Fp7e/yD5Z8sb4n5zrjxeTda+yvbpKcpiG0iu3sszP2y5ntm3fbXOHa8EQy abGEtekHzhD3RMlZs0Ld5mZpnPjx85XkuRytfBsJ90z3nSsltynd8LhVJPPysdLKt3d+6nkG LZi9peLqSr1M0TOZooemqi/w/qxTdSC8V/+wpxJLcUaioRZzUXEiAM6WhhG1AgAA X-CMS-MailID: 20190227131600eucas1p2a00cfc335786583e739b549634499a40 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20190227100249epcas1p1ef5547f3457c0964f32c97ea154d2b30 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20190227100249epcas1p1ef5547f3457c0964f32c97ea154d2b30 References: <20190227100235.14514-1-maxime.coquelin@redhat.com> <20190227100235.14514-3-maxime.coquelin@redhat.com> Subject: Re: [dpdk-dev] [RFC 2/2] vhost: support vhost-user request 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, 27 Feb 2019 13:16:03 -0000 On 27.02.2019 13:02, 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 catch the case where a request is neither handled > by the external backend nor by the vhost library. > > Signed-off-by: Maxime Coquelin > --- > lib/librte_vhost/vhost_user.c | 28 +++++++++++++++------------- > 1 file changed, 15 insertions(+), 13 deletions(-) > > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c > index 36c0c676d..bae5ef1cc 100644 > --- a/lib/librte_vhost/vhost_user.c > +++ b/lib/librte_vhost/vhost_user.c > @@ -1924,27 +1924,29 @@ vhost_user_msg_handler(int vid, int fd) > } > > ret = read_vhost_message(fd, &msg); > - if (ret <= 0 || msg.request.master >= VHOST_USER_MAX) { > + if (ret <= 0) { > if (ret < 0) > RTE_LOG(ERR, VHOST_CONFIG, > "vhost read message failed\n"); > - else if (ret == 0) > + else > RTE_LOG(INFO, VHOST_CONFIG, > "vhost peer closed\n"); > - else > - RTE_LOG(ERR, VHOST_CONFIG, > - "vhost read incorrect message\n"); > > return -1; > } > > ret = 0; > - if (msg.request.master != VHOST_USER_IOTLB_MSG) > - RTE_LOG(INFO, VHOST_CONFIG, "read message %s\n", > - vhost_message_str[msg.request.master]); > - else > - RTE_LOG(DEBUG, VHOST_CONFIG, "read message %s\n", > - vhost_message_str[msg.request.master]); > + request = msg.request.master; > + if (request < VHOST_USER_MAX && vhost_message_str[req]) { > + if (request != VHOST_USER_IOTLB_MSG) > + RTE_LOG(INFO, VHOST_CONFIG, "read message %s\n", > + vhost_message_str[request]); > + else if ( > + RTE_LOG(DEBUG, VHOST_CONFIG, "read message %s\n", > + vhost_message_str[request]); There is no need for the 'if' without the body. > + } else { > + RTE_LOG(INFO, VHOST_CONFIG, "External request %d\n", request); External requests could be annoying. Maybe we'll need to move them under DBG ? I'm not sure. > + } > > ret = vhost_user_check_and_alloc_queue_pair(dev, &msg); > if (ret < 0) { > @@ -1960,7 +1962,7 @@ vhost_user_msg_handler(int vid, int fd) > * inactive, so it is safe. Otherwise taking the access_lock > * would cause a dead lock. > */ > - switch (msg.request.master) { > + switch (request) { > case VHOST_USER_SET_FEATURES: > case VHOST_USER_SET_PROTOCOL_FEATURES: > case VHOST_USER_SET_OWNER: > @@ -1985,6 +1987,7 @@ vhost_user_msg_handler(int vid, int fd) > > } > > + ret = RTE_VHOST_MSG_RESULT_ERR; This will break the 'vhost_crypto', because it has no 'pre_msg_handler' and master will skip to 'post_msg_handler', but it will not be called because current status is ERR. Maybe it's easier to introduce RTE_VHOST_MSG_RESULT_NOT_HANDLED and convert it to ERR before the reply ? This will require changing the pre_msg_handlers to return RTE_VHOST_MSG_RESULT_NOT_HANDLED if message wasn't recognized. And we'll possibly be able to drop the 'skip_master' in this case. > if (dev->extern_ops.pre_msg_handle) { > ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, > (void *)&msg, &skip_master); > @@ -1997,7 +2000,6 @@ vhost_user_msg_handler(int vid, int fd) > goto skip_to_post_handle; > } > > - request = msg.request.master; > if (request > VHOST_USER_NONE && request < VHOST_USER_MAX) { > if (!vhost_message_handlers[request]) > goto skip_to_post_handle; >