[PATCH] doc: announce ivshmem support removal

[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: [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: [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: [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: doc: announce ivshmem support removal

[Maxime Coquelin]

On 07/20/2016 06: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 <thomas.monjalon@6wind.com>
> Acked-by: David Marchand <david.marchand@6wind.com>
>
> ---
> doc/guides/rel_notes/deprecation.rst | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Thanks!
Maxime

Re: doc: announce ivshmem support removal

[Jan Viktorin]

On Wed, 20 Jul 2016 18:35:46 +0200
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>
> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Acked-by: Jan Viktorin <viktorin@rehivetech.com

Re: doc: announce ivshmem support removal

[Christian Ehrhardt]

Hi Thomas,
just my two cents as Ubuntu DPDK maintainer (and part of the Debian Team
that does the same).
(It seems I can reuse that line for all posts about the deprecation notices
:-) )

While IVSHMEM was enabled (as it was the default) I never heard of any
users of what we provided so far.
But that is expected considering that not all qemu bits are landed either.
Since it will follow the process of "deprecation notice -> grace period ->
ABI bump" on removal, I think packaging and consuming applications should
be fine.

I'd agree to Hiroshi that, if really needed a clean re-implementation more
properly separated from EAL likely is the best way to go.

I think it is a good change to drop rather complex code in favor of
stabilizing the main paths:
Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Wed, Jul 27, 2016 at 9:08 PM, Jan Viktorin <viktorin@rehivetech.com>
wrote:

> On Wed, 20 Jul 2016 18:35:46 +0200
> 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>
> > Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>
> Acked-by: Jan Viktorin <viktorin@rehivetech.com
>

Re: doc: announce ivshmem support removal

[Mauricio Vasquez]

Hello All,

Here in Politecnico di Torino we use the ivshmem technology from a 
research point of view.

Our research efforts focus in optimizing the inter-Virtual Network 
Function communication, currently we have implemented two versions of 
our prototype, they are described in [1] and [2].

Unfortunately, we do not have the human resources to implement the 
improvements that are necessary for ivshmem in DPDK, however we could 
provide some feedback and testing for possible patches.

Best Regards,

Mauricio Vasquez.

[1] 
https://www.researchgate.net/publication/305699120_Transparent_Optimization_of_Inter-Virtual_Network_Function_Communication_in_Open_vSwitch

[2] 
https://www.researchgate.net/publication/305699122_A_Transparent_Highway_for_inter-Virtual_Network_Function_Communication_with_Open_vSwitch


On 07/28/2016 11:20 AM, Christian Ehrhardt wrote:
> Hi Thomas,
> just my two cents as Ubuntu DPDK maintainer (and part of the Debian Team
> that does the same).
> (It seems I can reuse that line for all posts about the deprecation notices
> :-) )
>
> While IVSHMEM was enabled (as it was the default) I never heard of any
> users of what we provided so far.
> But that is expected considering that not all qemu bits are landed either.
> Since it will follow the process of "deprecation notice -> grace period ->
> ABI bump" on removal, I think packaging and consuming applications should
> be fine.
>
> I'd agree to Hiroshi that, if really needed a clean re-implementation more
> properly separated from EAL likely is the best way to go.
>
> I think it is a good change to drop rather complex code in favor of
> stabilizing the main paths:
> Acked-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>
> On Wed, Jul 27, 2016 at 9:08 PM, Jan Viktorin <viktorin@rehivetech.com>
> wrote:
>
>> On Wed, 20 Jul 2016 18:35:46 +0200
>> 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>
>>> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Acked-by: Jan Viktorin <viktorin@rehivetech.com
>>

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

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

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