From: Tiwei Bie <tiwei.bie@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: maxime.coquelin@redhat.com, zhihong.wang@intel.com, dev@dpdk.org,
seanbh@gmail.com
Subject: Re: [PATCH 2/3] net/virtio-user: avoid parsing process mappings
Date: Fri, 7 Sep 2018 19:35:59 +0800 [thread overview]
Message-ID: <20180907113559.GA22407@debian> (raw)
In-Reply-To: <5bf3a5ef-790c-40af-d4ca-1fc748dd6c04@intel.com>
On Fri, Sep 07, 2018 at 10:39:16AM +0100, Burakov, Anatoly wrote:
> On 05-Sep-18 5:28 AM, Tiwei Bie wrote:
> > Recently some memory APIs were introduced to allow users to
> > get the file descriptor and offset for each memory segment.
> > We can leverage those APIs to get rid of the /proc magic on
> > memory table preparation in vhost-user backend.
> >
> > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > ---
>
> <snip>
>
> > - for (i = 0; i < num; ++i) {
> > - mr = &msg->payload.memory.regions[i];
> > - mr->guest_phys_addr = huges[i].addr; /* use vaddr! */
> > - mr->userspace_addr = huges[i].addr;
> > - mr->memory_size = huges[i].size;
> > - mr->mmap_offset = 0;
> > - fds[i] = open(huges[i].path, O_RDWR);
> > + if (rte_memseg_get_fd_offset_thread_unsafe(ms, &offset) < 0) {
> > + PMD_DRV_LOG(ERR, "Failed to get offset, ms=%p rte_errno=%d",
> > + ms, rte_errno);
> > + return -1;
> > + }
> > +
> > + start_addr = (uint64_t)(uintptr_t)ms->addr;
> > + end_addr = start_addr + ms->len;
> > +
> > + for (i = 0; i < wa->region_nr; i++) {
>
> There has to be a better way than to run this loop on every segment. Maybe
> store last-used region, and only do a region look up if there's a mismatch?
> Generally, in single-file segments mode, you'll get lots of segments from
> one memseg list one after the other, so you will need to do a lookup once
> memseg list changes, instead of on each segment.
We may have holes in one memseg list due to dynamic free.
Do you mean we just need to do rte_memseg_contig_walk()
and we can assume that fds of the contiguous memegs will
be the same?
>
> > + if (wa->fds[i] != fd)
> > + continue;
> > +
> > + mr = &wa->vm->regions[i];
> > +
> > + if (mr->userspace_addr + mr->memory_size < end_addr)
> > + mr->memory_size = end_addr - mr->userspace_addr;
> > +
>
> <snip>
>
> > int fds[VHOST_MEMORY_MAX_NREGIONS];
> > int fd_num = 0;
> > - int i, len;
> > + int len;
> > int vhostfd = dev->vhostfd;
> > RTE_SET_USED(m);
> > @@ -364,10 +337,6 @@ vhost_user_sock(struct virtio_user_dev *dev,
> > return -1;
> > }
> > - if (req == VHOST_USER_SET_MEM_TABLE)
> > - for (i = 0; i < fd_num; ++i)
> > - close(fds[i]);
> > -
>
> You're sharing fd's - presumably the other side of this is in a different
> process, so it's safe to close these fd's there?
Above code belongs to virtio-user, and it will close the
fds got from rte_memseg_get_fd_thread_unsafe().
Below is the code which will close these fds on the other
side (i.e. the vhost-user process):
https://github.com/DPDK/dpdk/blob/3605968c2fa7/lib/librte_vhost/vhost_user.c#L805
https://github.com/DPDK/dpdk/blob/3605968c2fa7/lib/librte_vhost/vhost_user.c#L97
>
> > if (need_reply) {
> > if (vhost_user_read(vhostfd, &msg) < 0) {
> > PMD_DRV_LOG(ERR, "Received msg failed: %s",
> >
>
>
> --
> Thanks,
> Anatoly
next prev parent reply other threads:[~2018-09-07 11:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 4:28 [PATCH 0/3] Some fixes/improvements for virtio-user memory table Tiwei Bie
2018-09-05 4:28 ` [PATCH 1/3] net/virtio-user: fix deadlock in memory events callback Tiwei Bie
2018-09-05 8:10 ` Sean Harte
2018-09-07 9:30 ` Burakov, Anatoly
2018-09-11 12:52 ` Maxime Coquelin
2018-09-05 4:28 ` [PATCH 2/3] net/virtio-user: avoid parsing process mappings Tiwei Bie
2018-09-07 9:39 ` Burakov, Anatoly
2018-09-07 11:35 ` Tiwei Bie [this message]
2018-09-07 12:21 ` Burakov, Anatoly
2018-09-10 3:59 ` Tiwei Bie
2018-09-17 10:17 ` Burakov, Anatoly
2018-09-17 11:57 ` Tiwei Bie
2018-09-17 13:06 ` Burakov, Anatoly
2018-09-11 12:58 ` Maxime Coquelin
2018-09-05 4:28 ` [PATCH 3/3] net/virtio-user: fix memory hotplug support in vhost-kernel Tiwei Bie
2018-09-07 9:44 ` Burakov, Anatoly
2018-09-07 11:37 ` Tiwei Bie
2018-09-07 12:24 ` Burakov, Anatoly
2018-09-10 4:04 ` Tiwei Bie
2018-09-17 10:18 ` Burakov, Anatoly
2018-09-11 13:10 ` Maxime Coquelin
2018-09-11 13:11 ` [PATCH 0/3] Some fixes/improvements for virtio-user memory table Maxime Coquelin
2018-09-20 7:35 ` 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=20180907113559.GA22407@debian \
--to=tiwei.bie@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=seanbh@gmail.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 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.