From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: Tetsuya Mukawa <mukawa@igel.co.jp>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "nakajima.yoshihiro@lab.ntt.co.jp"
<nakajima.yoshihiro@lab.ntt.co.jp>,
"mst@redhat.com" <mst@redhat.com>
Subject: Re: [PATCH v1 0/2] Virtio-net PMD Extension to work on host
Date: Mon, 11 Jan 2016 13:31:41 +0800 [thread overview]
Message-ID: <56933E3D.1090802@intel.com> (raw)
In-Reply-To: <568CC3A4.7080603@igel.co.jp>
Hi Tetsuya,
> With current your implementation, when 'virtual' virtio-net PMD is used,
> 'phys_addr' will be virtual address in EAL layer.
>
> struct rte_memseg {
> phys_addr_t phys_addr; /**< Start physical address. */
> union {
> void *addr; /**< Start virtual address. */
> uint64_t addr_64; /**< Makes sure addr is always 64
> bits */
> };
> .......
> };
It's not true. It does not effect EAL layer at all. Just fill virtual
address in virtio PMD when:
1). set_base_addr;
2). preparing RX's descriptors;
3). transmitting packets, CVA is filled in TX's descriptors;
4). in TX and CQ's header, CVA is used.
>
> How about choosing it in virtio-net PMD?
My current implementation works as you say.
> (In the case of 'virtual', just use 'addr' instead of using 'phys_addr'.)
> For example, port0 may use physical address, but port1 may use virtual
> address.
>
> With this, of course, we don't have an issue with 'physical' virtio-net PMD.
> Also, with 'virtual' virtio-net PMD, we can use virtual address and fd
> that represents the big virtual address space.
> (TODO: Need to change rte_memseg and EAL to keep fd and offset?)
I suppose you mean that when initializing memory, just maintain one fd
in the end, and
mmap all memsegs inside it. This sounds like a good idea to solve the
limitation of
VHOST_MEMORY_MAX_NREGIONS.
Besides, Sergio and I are discussing about using VA instead of PA in
VFIO to avoid the
requirement of physical-config for physical devices.
Thanks,
Jianfeng
> Then, you don't worry about VHOST_MEMORY_MAX_NREGIONS, because we have
> only one fd.
>
>> b. containers without root privilege
>> No need to worry about this problem, because it lacks of privilege to
>> construct physical-contiguous memory.
>>
> Yes, we cannot run 'physical' PMDs in this type of container.
> Anyway, I will check it more, if we really need it.
>
> Thanks,
> Tetsuya
next prev parent reply other threads:[~2016-01-11 5:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 10:57 [RFC PATCH 0/2] Virtio-net PMD Extension to work on host Tetsuya Mukawa
2015-11-19 10:57 ` [RFC PATCH 1/2] EAL: Add new EAL "--shm" option Tetsuya Mukawa
2015-12-16 8:37 ` [PATCH v1 0/2] Virtio-net PMD Extension to work on host Tetsuya Mukawa
2015-12-16 8:37 ` [PATCH v1 1/2] EAL: Add new EAL "--contig-mem" option Tetsuya Mukawa
2015-12-16 8:37 ` [PATCH v1 2/2] virtio: Extend virtio-net PMD to support container environment Tetsuya Mukawa
2015-12-28 11:57 ` Pavel Fedin
2016-01-06 3:57 ` Tetsuya Mukawa
2016-01-06 5:56 ` Tan, Jianfeng
2016-01-06 7:27 ` Tetsuya Mukawa
2015-12-24 14:05 ` [PATCH v1 0/2] Virtio-net PMD Extension to work on host Tan, Jianfeng
2015-12-28 11:06 ` Tetsuya Mukawa
2016-01-06 3:57 ` Tetsuya Mukawa
2016-01-06 5:42 ` Tan, Jianfeng
2016-01-06 7:35 ` Tetsuya Mukawa
2016-01-11 5:31 ` Tan, Jianfeng [this message]
2015-11-19 10:57 ` [RFC PATCH 2/2] virtio: Extend virtio-net PMD to support container environment Tetsuya Mukawa
2015-11-19 18:16 ` [RFC PATCH 0/2] Virtio-net PMD Extension to work on host Rich Lane
2015-11-20 2:00 ` Xie, Huawei
2015-11-20 2:35 ` Tetsuya Mukawa
2015-11-20 2:53 ` Tetsuya Mukawa
2015-12-28 5:15 ` Qiu, Michael
2015-12-28 11:06 ` Tetsuya Mukawa
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=56933E3D.1090802@intel.com \
--to=jianfeng.tan@intel.com \
--cc=dev@dpdk.org \
--cc=mst@redhat.com \
--cc=mukawa@igel.co.jp \
--cc=nakajima.yoshihiro@lab.ntt.co.jp \
/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.