Hi Thomas,
I'm going to develop a NFV based carrier system with SPP because it's able
to chain VMs in high-performance and I think it might be the best solution
for service function chaining. Without ivshmem, throuput between VMs is
largely decreased. So we are not so happy if ivshmem is obsoleted.
As you mentioned, we can use v16.07 but it's unwelcome situation for us and
our possible users cannot gain of improvements from future version of DPDK.
I'm appreciated if you kindly keep ivshmem to be maintained. Or, is there
any idea for high-performance inter-VM communication as ivshmem?
Regards,
Yasufumi Ogawa
Research Engineer
NTT Network Service Systems Labs
2016-08-04 17:00, 小川泰文:
Hi Thomas,
I'm going to develop a NFV based carrier system with SPP because it's able
to chain VMs in high-performance and I think it might be the best solution
for service function chaining. Without ivshmem, throuput between VMs is
largely decreased. So we are not so happy if ivshmem is obsoleted.
We are not obsoleting IVSHMEM which is a QEMU feature.
We are just dropping the automatic allocation of DPDK objects in the guest
through IVSHMEM.
It is a weird design that nobody really wants to maintain/redesign.
If someone wants to do the required work or reimplement it differently,
it may be accepted.
As you mentioned, we can use v16.07 but it's unwelcome situation for us and
our possible users cannot gain of improvements from future version of DPDK.
I'm appreciated if you kindly keep ivshmem to be maintained.
Nobody wants to really work on it. That's a fact, sorry.
Or, is there
any idea for high-performance inter-VM communication as ivshmem?
Yes you can implement an IVSHMEM driver in DPDK.
There was an attempt to do so which is also unmaintained:
http://dpdk.org/browse/old/memnic/
I think it would be a better approach than what exists currently.