DPDK patches and discussions
 help / color / mirror / Atom feed
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

      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).