From: "Xie, Huawei" <huawei.xie@intel.com>
To: Linhaifeng <haifeng.lin@huawei.com>,
'Tetsuya Mukawa' <mukawa@igel.co.jp>,
"dev@dpdk.org" <dev@dpdk.org>,
lilijun <jerry.lilijun@huawei.com>,
zhangkun <zhang.zhangkun@huawei.com>
Subject: Re: [dpdk-dev] vhost-user technical isssues
Date: Fri, 14 Nov 2014 06:24:39 +0000 [thread overview]
Message-ID: <C37D651A908B024F974696C65296B57B0F302931@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <546567C3.4040403@huawei.com>
> -----Original Message-----
> From: Linhaifeng [mailto:haifeng.lin@huawei.com]
> Sent: Thursday, November 13, 2014 7:24 PM
> To: Xie, Huawei; 'Tetsuya Mukawa'; dev@dpdk.org; lilijun; zhangkun
> Subject: Re: [dpdk-dev] vhost-user technical isssues
>
>
>
> On 2014/11/14 9:28, Xie, Huawei wrote:
> >
> >
> >> -----Original Message-----
> >> From: Linhaifeng [mailto:haifeng.lin@huawei.com]
> >> Sent: Wednesday, November 12, 2014 11:28 PM
> >> To: Xie, Huawei; 'Tetsuya Mukawa'; dev@dpdk.org
> >> Subject: Re: [dpdk-dev] vhost-user technical isssues
> >>
> >>
> >>
> >> On 2014/11/12 5:37, Xie, Huawei wrote:
> >>> Hi Tetsuya:
> >>> There are two major technical issues in my mind for vhost-user
> >> implementation.
> >>>
> >>> 1) memory region map
> >>> Vhost-user passes us file fd and offset for each memory region.
> Unfortunately
> >> the mmap offset is "very" wrong. I discovered this issue long time ago, and
> also
> >> found
> >>> that I couldn't mmap the huge page file even with correct offset(need
> double
> >> check).
> >>> Just now I find that people reported this issue on Nov 3.
> >>> [Qemu-devel] [PULL 27/29] vhost-user: fix mmap offset calculation
> >>> Anyway, I turned to the same idea used in our DPDK vhost-cuse: only use the
> fd
> >> for region(0) to map the whole file.
> >>> I think we should use this way temporarily to support qemu-2.1 as it has that
> >> bug.
> >>>
> >>
> >> the size of region 0 is not same as the file size. may be you should mmap the
> >> other region.
> > Haifeng:
> >
> > Will calculate the maximum memory size, and use any file fd to mmap it.
> > Here we assume the fds for different regions actually point to the same file.
>
> actually there may be two hugepage files created by qemu.
> one day i create a 4G VM found qemu create 2 hugepage file and send them to
> vhost-user.
> you can try to test it.
Ok, if that is the case, we need to fix vhost-cuse as well.
>
> >
> > In theory we should use the fd for each region to map each memory region.
> > In fact we could map once. This will also save address space for 1GB huge page
> > due to mmap alignment requirement.
> >>
> >> region 0:
> >> gpa = 0x0
> >> size = 655360
> >> ua = 0x2aaaaac00000
> >> offset = 0
> >>
> >> region 1:// use this region to mmap.BTW how to avoid mmap twice when
> there
> >> are two devices?
> >> gpa = 0xC0000
> >> size = 2146697216
> >> ua = 0x2aaaaacc0000
> >> offset = 786432
> >
> > What do you mean by two devices?
> >>
> >>
>
> e.g there are two vhost-user backends in a VM, we will receive two
> SET_MEM_TABLE messages, actually we only need mmap once in one message.
>
> I think qemu should add a new message to send all hugepage fd and size once.
> as this we not need to mmap and calculate memory in set_mem_table message.
>
> >>
> >>> 2) what message is the indicator for vhost start/release?
> >>> Previously for vhost-cuse, it has SET_BACKEND message.
> >>> What we should do for vhost-user?
> >>> SET_VRING_KICK for start?
> >>> What about for release?
> >>> Unlike the kernel virtio, the DPDK virtio in guest could be restarted.
> >>>
> >>> Thoughts?
> >>>
> >>> -huawei
> >>>
> >>>
> >>
> >> --
> >> Regards,
> >> Haifeng
> >
> >
> > .
> >
>
> --
> Regards,
> Haifeng
prev parent reply other threads:[~2014-11-14 6:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-11 21:37 Xie, Huawei
2014-11-12 4:12 ` Tetsuya Mukawa
2014-11-13 6:30 ` Linhaifeng
2014-11-14 2:30 ` Tetsuya Mukawa
2014-11-14 3:13 ` Linhaifeng
2014-11-14 3:40 ` Tetsuya Mukawa
2014-11-14 4:05 ` Tetsuya Mukawa
2014-11-14 4:42 ` Linhaifeng
2014-11-14 5:12 ` Tetsuya Mukawa
2014-11-14 5:30 ` Linhaifeng
2014-11-14 6:57 ` Tetsuya Mukawa
2014-11-14 10:59 ` Xie, Huawei
2014-11-17 6:14 ` Tetsuya Mukawa
2014-11-14 0:22 ` Xie, Huawei
2014-11-14 2:52 ` Tetsuya Mukawa
2014-11-15 1:42 ` Xie, Huawei
2014-11-13 6:12 ` Linhaifeng
2014-11-13 6:27 ` Linhaifeng
2014-11-14 1:28 ` Xie, Huawei
2014-11-14 2:24 ` Linhaifeng
2014-11-14 2:35 ` Tetsuya Mukawa
2014-11-14 6:24 ` Xie, Huawei [this message]
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=C37D651A908B024F974696C65296B57B0F302931@SHSMSX101.ccr.corp.intel.com \
--to=huawei.xie@intel.com \
--cc=dev@dpdk.org \
--cc=haifeng.lin@huawei.com \
--cc=jerry.lilijun@huawei.com \
--cc=mukawa@igel.co.jp \
--cc=zhang.zhangkun@huawei.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).