From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id CFDAF5ABE for ; Fri, 23 Jan 2015 04:36:34 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 22 Jan 2015 19:36:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,453,1418112000"; d="scan'208";a="674557159" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by orsmga002.jf.intel.com with ESMTP; 22 Jan 2015 19:36:28 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 23 Jan 2015 11:36:19 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.64]) by shsmsx102.ccr.corp.intel.com ([169.254.2.238]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:36:18 +0800 From: "Xie, Huawei" To: Linhaifeng , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support Thread-Index: AQHQFQiBhTFU6SC6J0OUJHzuD5S8bJzNTbtg Date: Fri, 23 Jan 2015 03:36:17 +0000 Message-ID: References: <1418247477-13920-1-git-send-email-huawei.xie@intel.com> <1418247477-13920-9-git-send-email-huawei.xie@intel.com> <548933D8.5000908@huawei.com> In-Reply-To: <548933D8.5000908@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 03:36:35 -0000 > -----Original Message----- > From: Linhaifeng [mailto:haifeng.lin@huawei.com] > Sent: Thursday, December 11, 2014 2:04 PM > To: Xie, Huawei; dev@dpdk.org > Cc: haifeng.lin@intel.com > Subject: Re: [dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user > support >=20 >=20 >=20 > On 2014/12/11 5:37, Huawei Xie wrote: > > vhost-user support > > > > > > Signed-off-by: Huawei Xie > > --- > > lib/librte_vhost/Makefile | 5 +- > > lib/librte_vhost/vhost-net.h | 4 + > > lib/librte_vhost/vhost_cuse/virtio-net-cdev.c | 9 + > > lib/librte_vhost/vhost_user/vhost-net-user.c | 422 > ++++++++++++++++++++++++++ > > + > > +static struct vhost_server *g_vhost_server; >=20 > Only support one vhost-user port ? The newer patch supports multiple vhost-user port. Will send next week. >=20 > > + > > +static const char *vhost_message_str[VHOST_USER_MAX] =3D { >=20 > why not use vserver_new_vq_conn(int fd, void* dat) ? >=20 > Since currently we only pass memory address and 32bit number, will change t= o void *. > > +{ > > + struct vhost_server *vserver =3D (void *)(uintptr_t)dat; > regions[VHOST_MEMORY_MAX_NREGIONS]; > > + uint64_t mapped_address, base_address =3D 0; > > + > > + for (idx =3D 0; idx < memory.nregions; idx++) { > > + if (memory.regions[idx].guest_phys_addr =3D=3D 0) > > + base_address =3D memory.regions[idx].userspace_addr; > > + } > > + if (base_address =3D=3D 0) { >=20 > when will base_address is 0? how to test to run this code? base_address with 0 is the requirement for vhost-cuse implementation. Normally it is the region [0, 0xA0000). In this version, we would keep this and not fix this. In future, will remov= e this. >=20 > > + RTE_LOG(ERR, VHOST_CONFIG, > > + "couldn't find the mem region whose GPA is 0.\n"); > > + return -1; > > + } > > + > > + for (idx =3D 0; idx < memory.nregions; idx++) { > > + regions[idx].guest_phys_address =3D > > + memory.regions[idx].guest_phys_addr; > > + regions[idx].guest_phys_address_end =3D > > + memory.regions[idx].guest_phys_addr + > > + memory.regions[idx].memory_size; > > + regions[idx].memory_size =3D memory.regions[idx].memory_size; > > + regions[idx].userspace_address =3D > > + memory.regions[idx].userspace_addr; > > + > > + /* This is ugly */ > > + mapped_address =3D (uint64_t)(uintptr_t)mmap(NULL, > > + regions[idx].memory_size + > > + memory.regions[idx].mmap_offset, > > + PROT_READ | PROT_WRITE, MAP_SHARED, > > + pmsg->fds[idx], > > + 0); >=20 > Can you mmap the region if gpa is 0? When i run VM with two numa node (qe= mu > will create two hugepage file) found that always failed to mmap with the = region > which gpa is 0. >=20 > BTW can we ensure the memory regions cover with all the memory of hugepag= e > for VM? >=20 We had discussed this. Seemed a qemu bug. Do you have update on this? > > + RTE_LOG(INFO, VHOST_CONFIG, > > + "mapped region %d to %p\n", > > +struct virtio_net_device_ops const *notify_ops; > > +struct virtio_net * get_device(struct vhost_device_ctx ctx); > > + > > +#endif > > >=20 > -- > Regards, > Haifeng Thanks Haifeng for your comments. Next time, could you help cut the code not commented? They are too long. It is really hard for me to find your comment.