[dpdk-dev] doc: announce ivshmem support removal

Message ID 1469032546-6256-1-git-send-email-thomas.monjalon@6wind.com (mailing list archive)
State Accepted, archived
Headers

Commit Message

Thomas Monjalon July 20, 2016, 4:35 p.m. UTC
  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(+)
  

Comments

Hiroshi Shimamoto July 22, 2016, 12:36 a.m. UTC | #1
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
  
Thomas Monjalon July 22, 2016, 7:52 a.m. UTC | #2
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.
  
David Marchand July 27, 2016, 8:38 a.m. UTC | #3
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>
  
Maxime Coquelin July 27, 2016, 4:12 p.m. UTC | #4
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
  
Jan Viktorin July 27, 2016, 7:08 p.m. UTC | #5
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
  
Christian Ehrhardt July 28, 2016, 9:20 a.m. UTC | #6
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
>
  
Mauricio Vasquez July 28, 2016, 3:23 p.m. UTC | #7
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
>>
  
Thomas Monjalon July 28, 2016, 6:09 p.m. UTC | #8
> > 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
  

Patch

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