patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ilya Maximets <i.maximets@samsung.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
	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" <mst@redhat.com>
Subject: Re: [dpdk-stable] [PATCH v2 01/17] vhost: fix messages error checks
Date: Thu, 4 Oct 2018 08:42:22 +0300	[thread overview]
Message-ID: <20181004054008eucas1p1ce42baf79937daf4c08cc127bbb92cbe~aUUu8tIPr2293922939eucas1p1S@eucas1p1.samsung.com> (raw)
In-Reply-To: <e2843403-5782-94f9-4b48-da7198e593cd@redhat.com>

On 03.10.2018 17:39, Maxime Coquelin wrote:
> 
> 
> 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 <maxime.coquelin@redhat.com>
>>>>>>>> ---
>>>>>>>>     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?

Sure. Thanks. I agree that it's not the right time for refactoring now.

> 
> Thanks,
> Maxime
> 
> 

  reply	other threads:[~2018-10-04  5:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02  9:36 [dpdk-stable] [PATCH v2 00/17] vhost: add postcopy live-migration support Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 01/17] vhost: fix messages error checks Maxime Coquelin
2018-10-02 14:15   ` Ilya Maximets
2018-10-03  7:50     ` Maxime Coquelin
2018-10-03  7:57       ` Ilya Maximets
2018-10-03  8:02         ` Maxime Coquelin
2018-10-03  8:32           ` Ilya Maximets
2018-10-03  9:07             ` Ilya Maximets
2018-10-03 14:39               ` Maxime Coquelin
2018-10-04  5:42                 ` Ilya Maximets [this message]
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 02/17] vhost: fix return code of messages requiring replies Maxime Coquelin
2018-10-03 13:26   ` Ilya Maximets
2018-10-03 14:49     ` Maxime Coquelin
2018-10-04  5:49       ` Ilya Maximets
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 03/17] vhost: fix error handling when mem table gets updated Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 04/17] vhost: define postcopy protocol flag Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 05/17] vhost: add number of fds to vhost-user messages and use it Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 06/17] vhost: pass socket fd to message handling callbacks Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 07/17] vhost: enable fds passing when sending vhost-user messages Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 08/17] vhost: add config flag for postcopy feature Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 09/17] vhost: introduce postcopy's advise message Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 10/17] vhost: add support for postcopy's listen message Maxime Coquelin
2018-10-02 14:11   ` Ilya Maximets
2018-10-03  7:46     ` Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 11/17] vhost: register new regions with userfaultfd Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 12/17] vhost: avoid useless VhostUserMemory copy Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 13/17] vhost: send userfault range addresses back to qemu Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 14/17] vhost: add support to postcopy's end request Maxime Coquelin
2018-10-02 14:18   ` Ilya Maximets
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 15/17] vhost: enable postcopy protocol feature Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 16/17] vhost: add flag to enable postcopy live-migration Maxime Coquelin
2018-10-02  9:36 ` [dpdk-stable] [PATCH v2 17/17] net/vhost: add parameter to enable postcopy support Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20181004054008eucas1p1ce42baf79937daf4c08cc127bbb92cbe~aUUu8tIPr2293922939eucas1p1S@eucas1p1.samsung.com' \
    --to=i.maximets@samsung.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=dgilbert@redhat.com \
    --cc=jfreimann@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=nicknickolaev@gmail.com \
    --cc=stable@dpdk.org \
    --cc=tiwei.bie@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).