| Message ID | 58AB0C46.5020601@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2017-02-20 15:33, Joao Martins: > On 02/17/2017 04:07 PM, Konrad Rzeszutek Wilk wrote: > > On Thu, Feb 16, 2017 at 10:51:44PM +0100, Vincent JARDIN wrote: > >> Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit : > >>>> Is it time now to officially remove Dom0 support? > >>> So we do have an prototype implementation of netback but it is waiting > >>> for review of xen-devel to the spec. > >>> > >>> And I believe the implementation does utilize some of the dom0 > >>> parts of code in DPDK. > >> > >> Please, do you have URLs/pointers about it? It would be interesting to share > >> it with DPDK community too. > > > > Joao, would it be possible to include an tarball of the patches? I know > > they are no in the right state with the review of the staging > > grants API - they are incompatible, but it may help folks to get > > a feel for what DPDK APIs you used? > OK, see attached - I should note that its a WIP as Konrad noted, but once the > staging grants work is finished, the code would be improved to have it in better > shape (as well as in feature parity) for a proper RFC [and adhering to the > project coding style]. Excuse my ignorance on Xen. Is xen-netback for Dom0? Is the DPDK Dom0 support working and useful?
Ping
The Xen dom0 support in DPDK seems dead.
Reminder:
Last time we talked about, it was because of a severe bug which is not
fixed yet:
http://dpdk.org/ml/archives/dev/2016-July/044207.html
http://dpdk.org/ml/archives/dev/2016-July/044376.html
The request (9 months ago) was to give more time for feedbacks:
http://dpdk.org/ml/archives/dev/2016-July/044847.html
23/02/2017 09:49, Thomas Monjalon:
> 2017-02-20 15:33, Joao Martins:
> > On 02/17/2017 04:07 PM, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 16, 2017 at 10:51:44PM +0100, Vincent JARDIN wrote:
> > >> Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit :
> > >>>> Is it time now to officially remove Dom0 support?
> > >>> So we do have an prototype implementation of netback but it is waiting
> > >>> for review of xen-devel to the spec.
> > >>>
> > >>> And I believe the implementation does utilize some of the dom0
> > >>> parts of code in DPDK.
> > >>
> > >> Please, do you have URLs/pointers about it? It would be interesting to share
> > >> it with DPDK community too.
> > >
> > > Joao, would it be possible to include an tarball of the patches? I know
> > > they are no in the right state with the review of the staging
> > > grants API - they are incompatible, but it may help folks to get
> > > a feel for what DPDK APIs you used?
> > OK, see attached - I should note that its a WIP as Konrad noted, but once the
> > staging grants work is finished, the code would be improved to have it in better
> > shape (as well as in feature parity) for a proper RFC [and adhering to the
> > project coding style].
>
> Excuse my ignorance on Xen.
> Is xen-netback for Dom0?
> Is the DPDK Dom0 support working and useful?
Hi Thomas and all, Apologize for being an unqualified maintainer. > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Friday, May 5, 2017 6:04 AM > To: Joao Martins; Konrad Rzeszutek Wilk; Tan, Jianfeng > Cc: Konrad Rzeszutek Wilk; dev@dpdk.org; Xen-devel > Subject: Re: [dpdk-dev] [PATCH] maintainers: claim responsability for xen > > Ping > > The Xen dom0 support in DPDK seems dead. > > Reminder: > Last time we talked about, it was because of a severe bug which is not > fixed yet: > http://dpdk.org/ml/archives/dev/2016-July/044207.html For this bug, we removed the userspace memset(0) and suppose it has been done by kernel, however, xen0 uses __get_free_pages() kernel API to map hugepages and reseve memseg, I think it makes sense to zero the hugepage for xen0 in rte_dom0_mm kernel module (instead of some special code for xen0 in userspace) to keep aligned behavior. > http://dpdk.org/ml/archives/dev/2016-July/044376.html It does not make any sense to upstream a netfront PMD before we have a netback PMD, as the legacy netback driver would be the bottleneck. Anyone has plan on this? And a question mark keeps in my mind that is it a must to implement netback in dom0? From another perspective, instead of using netfront/netback, we can also use virtio/vhost as the device model; however, xl tool in xen only supports vhost-kernel backend instead of vhost-user backend. So anyone has plan to enhance xl tool so that we can accelerate dom0 just using vswitch like OVS-DPDK? A third solution is to use xenvirtio as the frontend, and vhost_xen as the backend. This solution is to use virtio ring on grant table mechanism of xen. Honestly, I don't even know if it still work now. And to make it more usable, better to upstream vhost_xen inside popular vswitch like OVS-DPDK. > The request (9 months ago) was to give more time for feedbacks: > http://dpdk.org/ml/archives/dev/2016-July/044847.html Apologize again that I volunteer to maintain these files, but spend very few time on this. Thanks, Jianfeng
Thanks Jianfeng for giving new ideas. There is not much activity on Xen side. Is there someone working on DPDK+Xen? Any news? The technical board requested to re-consider Xen support in DPDK. It will be discussed in the next techboard meeting: https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db 11/05/2017 13:41, Tan, Jianfeng: > Hi Thomas and all, > > Apologize for being an unqualified maintainer. > > > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > Ping > > > > The Xen dom0 support in DPDK seems dead. > > > > Reminder: > > Last time we talked about, it was because of a severe bug which is not > > fixed yet: > > http://dpdk.org/ml/archives/dev/2016-July/044207.html > > For this bug, we removed the userspace memset(0) and suppose it has been done by kernel, however, xen0 uses __get_free_pages() kernel API to map hugepages and reseve memseg, I think it makes sense to zero the hugepage for xen0 in rte_dom0_mm kernel module (instead of some special code for xen0 in userspace) to keep aligned behavior. > > > http://dpdk.org/ml/archives/dev/2016-July/044376.html > > It does not make any sense to upstream a netfront PMD before we have a netback PMD, as the legacy netback driver would be the bottleneck. Anyone has plan on this? And a question mark keeps in my mind that is it a must to implement netback in dom0? > > From another perspective, instead of using netfront/netback, we can also use virtio/vhost as the device model; however, xl tool in xen only supports vhost-kernel backend instead of vhost-user backend. So anyone has plan to enhance xl tool so that we can accelerate dom0 just using vswitch like OVS-DPDK? > > A third solution is to use xenvirtio as the frontend, and vhost_xen as the backend. This solution is to use virtio ring on grant table mechanism of xen. Honestly, I don't even know if it still work now. And to make it more usable, better to upstream vhost_xen inside popular vswitch like OVS-DPDK. > > > The request (9 months ago) was to give more time for feedbacks: > > http://dpdk.org/ml/archives/dev/2016-July/044847.html > > Apologize again that I volunteer to maintain these files, but spend very few time on this. > > Thanks, > Jianfeng
From 726567a34c537d27285f65657c2c34a941093e91 Mon Sep 17 00:00:00 2001 From: Joao Martins <joao.m.martins@oracle.com> Date: Mon, 20 Feb 2017 13:33:34 +0000 Subject: [PATCH WIP 2/2] config: add xen-netback PMD option Default is disabled. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> --- config/common_base | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/config/common_base b/config/common_base index 7830535..a2f0330 100644 --- a/config/common_base +++ b/config/common_base @@ -563,11 +563,16 @@ CONFIG_RTE_LIBRTE_VHOST_DEBUG=n CONFIG_RTE_LIBRTE_PMD_VHOST=n # -#Compile Xen domain0 support +# Compile Xen domain0 support # CONFIG_RTE_LIBRTE_XEN_DOM0=n # +# Compile Xen netback PMD +# +CONFIG_RTE_LIBRTE_PMD_XEN_NETBACK=n + +# # Enable warning directives # CONFIG_RTE_INSECURE_FUNCTION_WARNING=n -- 2.1.4