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 41D761B3E8; Wed, 3 Oct 2018 16:39:40 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7560F30BB374; Wed, 3 Oct 2018 14:39:39 +0000 (UTC) Received: from [10.36.112.44] (ovpn-112-44.ams2.redhat.com [10.36.112.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C07DB6715C; Wed, 3 Oct 2018 14:39:24 +0000 (UTC) To: Ilya Maximets , dev@dpdk.org, tiwei.bie@intel.com, zhihong.wang@intel.com, jfreimann@redhat.com, nicknickolaev@gmail.com, bruce.richardson@intel.com, alejandro.lucero@netronome.com Cc: dgilbert@redhat.com, stable@dpdk.org, "Michael S. Tsirkin" References: <20181002093651.24795-1-maxime.coquelin@redhat.com> <20181002093651.24795-2-maxime.coquelin@redhat.com> <20181002141315eucas1p16c87759329eeb374528bcb70a2d71ee4~Z0CLLGpN92076620766eucas1p1R@eucas1p1.samsung.com> <2a57953d-67c6-26f3-f65f-4e5a1dcf1474@redhat.com> <20181003075530eucas1p1dd7191a728c1129fd5d9dbaed5fa1047~aChpN_6wn1404114041eucas1p1H@eucas1p1.samsung.com> <20181003083009eucas1p19f5d8234a3592b9e1753181d858a99aa~aC-5VXlJ51559815598eucas1p1k@eucas1p1.samsung.com> <20181003090454eucas1p180d79e1279ca4e1086b2447758686978~aDeOgna1t0120201202eucas1p1W@eucas1p1.samsung.com> From: Maxime Coquelin Message-ID: Date: Wed, 3 Oct 2018 16:39:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181003090454eucas1p180d79e1279ca4e1086b2447758686978~aDeOgna1t0120201202eucas1p1W@eucas1p1.samsung.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Wed, 03 Oct 2018 14:39:39 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v2 01/17] vhost: fix messages error checks 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, 03 Oct 2018 14:39:40 -0000 On 10/03/2018 11:07 AM, Ilya Maximets wrote: > On 03.10.2018 11:32, Ilya Maximets wrote: >> On 03.10.2018 11:02, Maxime Coquelin wrote: >>> >>> >>> On 10/03/2018 09:57 AM, Ilya Maximets wrote: >>>> On 03.10.2018 10:50, Maxime Coquelin wrote: >>>>> >>>>> >>>>> On 10/02/2018 04:15 PM, Ilya Maximets wrote: >>>>>> On 02.10.2018 12:36, Maxime Coquelin wrote: >>>>>>> Return of message handling has now changed to an enum that can >>>>>>> take non-negative value that is not zero in case a reply is >>>>>>> needed. But the code checking the variable afterwards has not >>>>>>> been updated, leading to success messages handling being >>>>>>> treated as errors. >>>>>>> >>>>>>> Fixes: 4e601952cae6 ("vhost: message handling implemented as a callback array") >>>>>>> >>>>>>> Signed-off-by: Maxime Coquelin >>>>>>> --- >>>>>>>    lib/librte_vhost/vhost_user.c | 6 +++--- >>>>>>>    1 file changed, 3 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c >>>>>>> index 7ef3fb4a4..060b41893 100644 >>>>>>> --- a/lib/librte_vhost/vhost_user.c >>>>>>> +++ b/lib/librte_vhost/vhost_user.c >>>>>>> @@ -1783,7 +1783,7 @@ vhost_user_msg_handler(int vid, int fd) >>>>>>>        } >>>>>>>      skip_to_post_handle: >>>>>>> -    if (!ret && dev->extern_ops.post_msg_handle) { >>>>>>> +    if (ret != VH_RESULT_ERR && dev->extern_ops.post_msg_handle) { >>>>>>>            uint32_t need_reply; >>>>>>>              ret = (*dev->extern_ops.post_msg_handle)( >>>>>>> @@ -1800,10 +1800,10 @@ vhost_user_msg_handler(int vid, int fd) >>>>>>>            vhost_user_unlock_all_queue_pairs(dev); >>>>>>>          if (msg.flags & VHOST_USER_NEED_REPLY) { >>>>>> >>>>>> Maybe we need to reply here only if we didn't reply >>>>>> already (not VH_RESULT_REPLY) ? Otherwise, we could >>>>>> reply twice (with payload and with return code). >>>>> >>>>> Well, if the master sets this bit, it means it is waiting for >>>>> a "reply-ack", so not sending it would cause the master to wait >>>>> forever. >>>>> >>>>> It is the master responsibility to not set this bit for requests >>>>> already expecting a non "reply-ack" reply (as you fixed it for >>>>> postcopy's set mem table case). >>>> >>>> vhost-user docs in QEMU says: >>>> " >>>> For the message types that already solicit a reply from the client, the >>>> presence of VHOST_USER_PROTOCOL_F_REPLY_ACK or need_reply bit being set brings >>>> no behavioural change. >>>> " >>>> i.e. even if QEMU sets the need_reply flag, vhost should not reply twice. >>>> Am I missing something? >>> >>> Oh, right. Thanks for pointing it out. >>> >>> So coming back to the DPDK implementation, I just had a look again, and it seems that we don't send a reply twice, as send_vhost_reply takes >>> care of clearing the VHOST_USER_NEED_REPLY flag. >>> Do you confirm my understanding is correct? >> >> Hmm. Yes, you're right. send_vhost_reply clears the VHOST_USER_NEED_REPLY >> flag and vhost doesn't send replies twice. >> Maybe some comment with clarifications needed here, or some more >> refactoring to make this aspect more clear. >> Agree. I'm adding a comment, I don't think a refactoring is required, and I would be reluctant to add one more refactoring so close to the integration deadline. Does it work for you? Thanks, Maxime