From: Tetsuya Mukawa <mukawa@igel.co.jp>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: dev@dpdk.org, jianfeng.tan@intel.com, huawei.xie@intel.com
Subject: Re: [PATCH v2] vhost: Fix default value of kickfd and callfd
Date: Mon, 14 Mar 2016 17:31:26 +0900 [thread overview]
Message-ID: <56E676DE.10407@igel.co.jp> (raw)
In-Reply-To: <20160314082125.GM979@yliu-dev.sh.intel.com>
On 2016/03/14 17:21, Yuanhan Liu wrote:
> On Mon, Mar 14, 2016 at 04:54:00PM +0900, Tetsuya Mukawa wrote:
>> On 2016/03/14 11:08, Yuanhan Liu wrote:
>>> On Mon, Mar 14, 2016 at 10:54:14AM +0900, Tetsuya Mukawa wrote:
>>>> On 2016/03/11 16:19, Yuanhan Liu wrote:
>>>>> On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote:
>>>>>> Currently, default values of kickfd and callfd are -1.
>>>>>> If the values are -1, current code guesses kickfd and callfd haven't
>>>>>> been initialized yet. And vhost library will guess the virtqueue isn't
>>>>>> ready for processing.
>>>>>> But callfd and kickfd will be set as -1 when "--enable-kvm"
>>>>>> isn't specified in QEMU command line. It means we cannot treat -1 as
>>>>>> uninitialized state. The patch changes default values to -2. And the
>>>>>> patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD.
>>>>> This looks more like a workaround to me.
>>>> Hi Yuanhan,
>>>>
>>>> Sorry for late reply.
>>>> I have checked QEMU documentation, and found below.
>>>>
>>>> ----------
>>>> * VHOST_USER_SET_VRING_CALL
>>>>
>>>> Id: 14
>>>> Equivalent ioctl: VHOST_SET_VRING_CALL
>>>> Master payload: u64
>>>>
>>>> Set the event file descriptor to signal when buffers are used. It
>>>> is passed in the ancillary data.
>>>> Bits (0-7) of the payload contain the vring index. Bit 8 is the
>>>> invalid FD flag.
>>>> ----------
>>>>
>>>> VHOST_USER_SET_VRING_KICK has almost same description.
>>>> I will check this invalid flag, and if it works for our case, then will
>>>> use it.
>>>> How about it?
>>> Yeah, that indeed sounds much better.
>> I've checked current dpdk code.
>> It seems we've already checked invalid flag like below.
>>
>> if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
>> file.fd = -1;
>> else
>> file.fd = pmsg->fds[0];
>>
>> So how about adding below macros or enum?
>>
>> #define VIRTIO_UNINITIALIZED_EVENTFD (-2)
>> #define VIRTIO_INVALID_EVENTFD (-1)
>>
>> I am still not sure whether using enum is better or not.
> Both are Okay to me; I have no preference on that.
>
>> But here is one of example patch.
>> What do you think?
> Looks okay to me
>
>> diff --git a/lib/librte_vhost/rte_virtio_net.h
>> b/lib/librte_vhost/rte_virtio_net.h
>> index 7d1fde2..2a7566d 100644
>> --- a/lib/librte_vhost/rte_virtio_net.h
>> +++ b/lib/librte_vhost/rte_virtio_net.h
>> @@ -89,6 +89,8 @@ struct vhost_virtqueue {
>> uint16_t vhost_hlen; /**< Vhost
>> header length (varies depending on RX merge buffers. */
>> volatile uint16_t last_used_idx; /**< Last index
>> used on the available ring */
>> volatile uint16_t last_used_idx_res; /**< Used for
>> multiple devices reserving buffers. */
>> +#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
>> +#define VIRTIO_INVALID_EVENTFD (-1)
> One nit: you may keep it in order.
Thanks for your comments, will change it.
Tetsuya
> --yliu
next prev parent reply other threads:[~2016-03-14 8:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 6:14 [PATCH] vhost: Fix default value of kickfd and callfd Tetsuya Mukawa
2016-03-10 6:25 ` Tan, Jianfeng
2016-03-10 6:34 ` Tetsuya Mukawa
2016-03-10 6:39 ` Tan, Jianfeng
2016-03-10 6:42 ` Tetsuya Mukawa
2016-03-10 7:06 ` [PATCH v2] " Tetsuya Mukawa
2016-03-11 7:19 ` Yuanhan Liu
2016-03-14 1:54 ` Tetsuya Mukawa
2016-03-14 2:08 ` Yuanhan Liu
2016-03-14 7:54 ` Tetsuya Mukawa
2016-03-14 8:21 ` Yuanhan Liu
2016-03-14 8:31 ` Tetsuya Mukawa [this message]
2016-03-14 8:53 ` [PATCH v3] " Tetsuya Mukawa
2016-03-14 9:12 ` Yuanhan Liu
2016-03-14 23:19 ` Thomas Monjalon
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=56E676DE.10407@igel.co.jp \
--to=mukawa@igel.co.jp \
--cc=dev@dpdk.org \
--cc=huawei.xie@intel.com \
--cc=jianfeng.tan@intel.com \
--cc=yuanhan.liu@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.