Re: [dpdk-dev] [PATCH] doc: announce ivshmem support removal

Re: [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

Re: [dpdk-dev] [PATCH] doc: announce ivshmem support removal

[Thomas Monjalon]

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

[Thomas Monjalon]

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 <thomas.monjalon@6wind.com>
---
 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

Re: [dpdk-dev] [PATCH] doc: announce ivshmem support removal

[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.

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 <thomas.monjalon@6wind.com>
> ---
>  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

Re: [dpdk-dev] [PATCH] doc: announce ivshmem support removal

[Thomas Monjalon]

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.

Re: [dpdk-dev] [PATCH] doc: announce ivshmem support removal

[David Marchand]

On Wed, Jul 20, 2016 at 6:35 PM, Thomas Monjalon
<thomas.monjalon@6wind.com> 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 <thomas.monjalon@6wind.com>

Acked-by: David Marchand <david.marchand@6wind.com>


-- 
David Marchand

Re: [dpdk-dev] [PATCH] doc: announce ivshmem support removal

[Thomas Monjalon]

> > 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 <thomas.monjalon@6wind.com>
> 
> Acked-by: David Marchand <david.marchand@6wind.com>
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Acked-by: Jan Viktorin <viktorin@rehivetech.com>
Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Applied