Open Stack

Hi Nova team,

It has been quite a long time since the last discussion,
but let me make sure one thing about the thread below.

IIUC, Nova is not welcome ivshmem support because it is no longer 
supported by DPDK+QEMU.

But how would you say if it is supported out of DPDK-tree and can be 
used from the newest qemu version ?

We are now developing SPP, a DPDK-based vswitch, and thinking about 
trying to implement ivshmem support under our SPP code tree if nova (or 
at first libvirt community) is acceptable for ivshmem configuration.

Your advice will be very helpful for our decision-making in our project.

Thanks in advance,
Tetsuro Nakamura

On 2017/05/08 22:09, Daniel P. Berrange wrote:
> On Fri, Apr 28, 2017 at 09:38:38AM +0100, sfinucan at redhat.com wrote:
>> On Fri, 2017-04-28 at 13:23 +0900, TETSURO NAKAMURA wrote:
>>> Hi Nova team,
>>>
>>> I'm writing this e-mail because I'd like to have a discussion about
>>> DPDK support at OpenStack Summit in Boston.
>>>
>>> We have developed a dpdk-based patch panel named SPP[1], and we'd
>>> like to start working on Openstack (ML2 driver) to develop
>>> "networking-spp".
>>>
>>> Especially, we'd like to use DPDK-ivshmem that was used to be used
>>> to create "dpdkr" interface in ovs-dpdk[2].
>>
>> To the best of my knowledge, IVSHMEM ports are no longer supported in
>> upstream. The documentation for this feature was recently removed from
>> OVS [1] stating:
>>
>>    - The ivshmem library has been removed in DPDK since DPDK 16.11.
>>    - The instructions/scheme provided will not work with current
>>      supported and future DPDK versions.
>>    - The linked patch needed to enable support in QEMU has never
>>      been upstreamed and does not apply to the last 4 QEMU releases.
>>    - Userspace vhost has become the defacto OVS-DPDK path to the guest.
>>
>> Note: I worked on DPDK vSwitch [2] way back when, and there were severe
>> security implications with sharing a chunk of host memory between
>> multiple guests (which is how IVSHMEM works). I'm not at all surprised
>> the feature was killed.
> 
> Security is only one of the issues. Upstream QEMU maintainers considered
> the ivshmem device to have a seriously flawed design and discourage anyone
> from using it. For anything network related QEMU maintainers strongly
> recommand using vhost-user.
> 
> IIUC, there is some experimental work to create a virtio based replacement
> for ivshmem, for non-network related vm-2-vm communications, but that is
> not going to be something usable for a while yet. This however just
> reinforces the point that ivshmem is considered obsolete / flawed
> technology by QEMU maintainers.
> 
> Regards,
> Daniel
> 

-- 
Tetsuro Nakamura <nakamura.tetsuro at lab.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan