Message ID | 1469032546-6256-1-git-send-email-thomas.monjalon@6wind.com (mailing list archive) |
---|---|
State | Accepted, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id D6AB6378B; Wed, 20 Jul 2016 18:35:54 +0200 (CEST) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 5B7AE377C for <dev@dpdk.org>; Wed, 20 Jul 2016 18:35:53 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id o80so77246293wme.1 for <dev@dpdk.org>; Wed, 20 Jul 2016 09:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=nyCHV7TsSK28xN0hBOuQrjc+nuj9L0NjBlvtttaEwB8=; b=NDYinyPFBWjHtyiq5qDE0cQMtWgF57MqcyNVCm0uj3zoYM2y2R14j4ImDH2/4WqWS1 XpSRcXjIxnHtpv4uBYJcSRCuc8ummn6++dKAPZIsv65MYqIZitfWjQLp1QA2eimxLcSM Fk7AyzTDxUDJXv//QYzcaOX1fsgiiJkZZ4wDT/c7moiHvBIEO5z8dfgC3c0iNPWYuYNm q0+8eFakMGyg+wyYvS3CwZzuPMaDxw9dR+1kJy3s9mcweha45HaX0R2d+LV3teRE41a9 g55+FxoJG2Cljrrqw0xhLmTIvVMAF0JiXGj5Ql7lOFlrBbBHurf4O6t3ToqY+mKYigVD uieA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=nyCHV7TsSK28xN0hBOuQrjc+nuj9L0NjBlvtttaEwB8=; b=j73eUNwQW/F63djfQC01gkPuZsjuI8mAgHaVMH1OA/bHsbas0JXwIQK0jC/uAs0gME 80AcCX/7KNnad9zqA4koml6nbKrw9X7wMkwuialbaI5eiosfq1h9v7f/hfyiyvthFOge AkJWKOmaMdcNCepklnQULDSzBqO8XPFlWnj742phDv4NkOOW3Xdk6zn9vlg+3/iHT+AH kDCH96oDwDS32Eb9mWXR0r+JiJDaGKofX2kThwrSQfGssqE+23B5rWbKtfUK2XUeKbKG mB7zv563COn49wunNs70pt3uBNKcNbJ5c/lJA5bjlTheRhZ76fLbw6L3fO/Y5LJwy+QQ V0RA== X-Gm-Message-State: ALyK8tJ28UdY7pyIccuXwN0Z7rdt058sYCj782arCdFV5aBa015dM4dqaPRKDZ+ZDvC2osT7 X-Received: by 10.195.18.3 with SMTP id gi3mr2470474wjd.173.1469032553108; Wed, 20 Jul 2016 09:35:53 -0700 (PDT) Received: from XPS13.localdomain (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id lh10sm2053790wjc.12.2016.07.20.09.35.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 09:35:51 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: anatoly.burakov@intel.com Cc: dev@dpdk.org Date: Wed, 20 Jul 2016 18:35:46 +0200 Message-Id: <1469032546-6256-1-git-send-email-thomas.monjalon@6wind.com> X-Mailer: git-send-email 2.7.0 Subject: [dpdk-dev] [PATCH] doc: announce ivshmem support removal X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
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
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
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.
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>
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
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
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 >
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 >>
> > 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
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