[dpdk-dev] [PATCH] doc: announce ivshmem support removal
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.
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
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
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
On Wed, Jul 20, 2016 at 6:35 PM, Thomas Monjalon wrote: > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
2016-07-22 00:36, Hiroshi Shimamoto: > Hi, > > > Subject: [dpdk-dev] [PATCH] doc: announce ivshmem support removal > > > > There was a prior call with an explanation of what needs to be done: > > http://dpdk.org/ml/archives/dev/2016-June/040844.html > > - Qemu patch upstreamed > > - IVSHMEM PCI device managed by a PCI driver > > - No DPDK objects (ring/mempool) allocated by EAL > > > > As nobody seems interested, it is time to remove this code which > > makes EAL improvements harder. > > I'd like to confirm about the issue. > I know there are real users who rely on ivshmem mechanism. e.g. spp user. > Unfortunately they don't prefer to expose their opinion to the community. > Furthermore they may not have noticed this situation. These secret users can use the version 16.07. > Anyway, it is the issue that the current ivshmem implementation breaks > EAL framework and is much complicated, right? > IIUC, for DPDK, ivshmem support module should be separated from a middle of > EAL code and make it as a PCI driver. That means the current rte_ivshmem > removal should happen. To keep the functionality to share DPDK objects > between host and guest in shared memory like ivshmem, it should be > implemented cleanly. > Is my understanding correct? Yes You just forgot the need for a patch on Qemu.
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
Hi, > Subject: [dpdk-dev] [PATCH] doc: announce ivshmem support removal > > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. I'd like to confirm about the issue. I know there are real users who rely on ivshmem mechanism. e.g. spp user. Unfortunately they don't prefer to expose their opinion to the community. Furthermore they may not have noticed this situation. Anyway, it is the issue that the current ivshmem implementation breaks EAL framework and is much complicated, right? IIUC, for DPDK, ivshmem support module should be separated from a middle of EAL code and make it as a PCI driver. That means the current rte_ivshmem removal should happen. To keep the functionality to share DPDK objects between host and guest in shared memory like ivshmem, it should be implemented cleanly. Is my understanding correct? thanks, Hiroshi > > Signed-off-by: Thomas Monjalon > --- > doc/guides/rel_notes/deprecation.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 9cadf6a..1ef8460 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -42,6 +42,9 @@ Deprecation Notices >will be removed in 16.11. >It is replaced by rte_mempool_generic_get/put functions. > > +* The ``rte_ivshmem`` feature (including library and EAL code) will be > removed > + in 16.11 because it has some design issues which are not planned to be > fixed. > + > * The ethtool support will be removed from KNI in 16.11. >It is implemented only for igb and ixgbe. >It is really hard to maintain because it requires some out-of-tree kernel > -- > 2.7.0
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
There was a prior call with an explanation of what needs to be done: http://dpdk.org/ml/archives/dev/2016-June/040844.html - Qemu patch upstreamed - IVSHMEM PCI device managed by a PCI driver - No DPDK objects (ring/mempool) allocated by EAL As nobody seems interested, it is time to remove this code which makes EAL improvements harder. Signed-off-by: Thomas Monjalon --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 9cadf6a..1ef8460 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -42,6 +42,9 @@ Deprecation Notices will be removed in 16.11. It is replaced by rte_mempool_generic_get/put functions. +* The ``rte_ivshmem`` feature (including library and EAL code) will be removed + in 16.11 because it has some design issues which are not planned to be fixed. + * The ethtool support will be removed from KNI in 16.11. It is implemented only for igb and ixgbe. It is really hard to maintain because it requires some out-of-tree kernel -- 2.7.0
