Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Thomas Monjalon]

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:tho...@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




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Tan, Jianfeng]

Hi  Thomas and all,

Apologize for being an unqualified maintainer.

> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, May 5, 2017 6:04 AM
> To: Joao Martins; Konrad Rzeszutek Wilk; Tan, Jianfeng
> Cc: Konrad Rzeszutek Wilk; d...@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

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Thomas Monjalon]

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?


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

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

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Joao Martins]

On 02/20/2017 09:56 AM, Jan Blunck wrote:
> On Fri, Feb 17, 2017 at 5: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?
>>
>> Staging grants API:
>> https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01878.html
> 
> The topic of the grants API is unrelated to the dom0 memory pool. The
> memory pool which uses xen_create_contiguous_region() is used in cases
> we know that there are no hugepages available.
Correct, I think what Konrad was trying to say was that xen-netback normally
lives in a PV domain which doesn't have superpages, therefore such driver would
need that memory pool part in order to work. The mentioned spec are additions to
xen netif ABI for backend to safely map a fixed set of grant references
(recycled overtime, provided by frontend) with the purpose of avoiding grant ops
- DPDK would be one of the users.

> Joao and I met in Dublin and I whined about not being able to call
> into the grants API from userspace and instead need to kick a kernel
> driver to do the work for every burst. It would be great if that could
> change in the future.
Hm, I recall about that discussion. AFAIK you can do both grant alloc/revoke of
pages through xengntshr_share_pages(...) and xengntshr_unshare(...) APIs
provided by libxengnttab[0] starting 4.7 or, libxc on older versions with
xc_gntshr_share_pages/xc_gntshr_munmap[2]. For the notification (or kicks) you
can allocate the event channel in the guest with libevtchn[1] starting 4.7, with
xenevtchn_bind_unbound_port(...) or libxc on older versions with
xc_evtchn_bind_unbound_port(...)[2]. And kick the guest with xenevtchn_notify or
xc_evtchn_notify(...) [latter on older versions]. In short these APIs are ioctls
to /dev/gntdev and /dev/evtchn. xenstore operations can also be done in
userspace with libxenstore[3].

To have the (similar) behavior of VRING_AVAIL_F_NO_INTERRUPT (i.e. avoiding the
kicks) you "just" don't set rsp_event in ring (e.g. no calls to
RING_FINAL_CHECK_FOR_RESPONSES), and keep checking for unconsumed Rx/Tx
responses. For guest request notification (to wake up the backend for new Tx/Rx
requests), you're dependent on whether backend requests it since it's the one
setting req_event index. If it indeed sets it then you gotta use the evtchn
notify that I depicted in the previous paragraph.

Hope that helps!

Joao

[0]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libs/gnttab/include/xengnttab.h;hb=HEAD
[1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libs/evtchn/include/xenevtchn.h;hb=HEAD
[2]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxc/include/xenctrl_compat.h;hb=HEAD
[3]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/xenstore/include/xenstore.h;hb=HEAD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

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

Joao
>From 3bced1452e1e619e7f4701cf67ba88c2627aa376 Mon Sep 17 00:00:00 2001
From: Joao Martins 
Date: Mon, 20 Feb 2017 13:33:34 +
Subject: [PATCH WIP 1/2] drivers/net: add xen-netback PMD

Introduce Xen network backend support, namely xen-netback.
This mostly means adding a boilerplate driver with a initially
reduced set of features (i.e. without feature-sg and no multi queue).
It handles grant operations and notifications correctly, and almost
all state machine. Additionally it supports one early version of
staging grants (here after feature-persistent=1) to allow DPDK to
have a set of premapped grants and hence avoid the grant copy
(slow)paths. This driver is implemented using xen provided libraries
for event channels, gnttab and xenstore operations.

Signed-off-by: Joao Martins 
---
 drivers/net/Makefile   |   1 +
 drivers/net/xen-netback/Makefile   |  68 ++
 .../xen-netback/rte_pmd_xen-netback_version.map|   3 +
 drivers/net/xen-netback/xnb.h  | 159 
 drivers/net/xen-netback/xnb_ethdev.c   | 701 +++
 drivers/net/xen-netback/xnb_ethdev.h   |  34 +
 drivers/net/xen-netback/xnb_ring.c | 240 +
 drivers/net/xen-netback/xnb_rxtx.c | 683 +++
 drivers/net/xen-netback/xnb_xenbus.c   | 975 +
 mk/rte.app.mk  |   1 +
 10 files changed, 2865 insertions(+)
 create mode 100644 drivers/net/xen-netback/Makefile
 create mode 100644 drivers/net/xen-netback/rte_pmd_xen-netback_version.map
 create mode 100644 drivers/net/xen-netback/xnb.h
 create mode 100644 drivers/net/xen-netback/xnb_ethdev.c
 create mode 100644 drivers/net/xen-netback/xnb_ethdev.h
 create mode 100644 drivers/net/xen-netback/xnb_ring.c
 create mode 100644 drivers/net/xen-netback/xnb_rxtx.c
 create mode 100644 drivers/net/xen-netback/xnb_xenbus.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index bc93230..a4bf7cb 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -55,6 +55,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD) += thunderx
 DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
 DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_XEN_NETBACK) += xen-netback
 
 ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += vhost
diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
new file mode 100644
index 000..c6299b0
--- /dev/null
+++ b/drivers/net/xen-netback/Makefile
@@ -0,0 +1,68 @@
+# BSD LICENSE
+#
+# Copyright(c) 2016, Oracle and/or its affiliates. All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+#   * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+#   * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+#   * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR 

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Jan Blunck]

On Fri, Feb 17, 2017 at 5: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?
>
> Staging grants API:
> https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01878.html
>

The topic of the grants API is unrelated to the dom0 memory pool. The
memory pool which uses xen_create_contiguous_region() is used in cases
we know that there are no hugepages available.

Joao and I met in Dublin and I whined about not being able to call
into the grants API from userspace and instead need to kick a kernel
driver to do the work for every burst. It would be great if that could
change in the future.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Konrad Rzeszutek Wilk]

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?

Staging grants API:
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01878.html

> 
> Best regards,
>   Vincent

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Vincent JARDIN]

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.


Best regards,
  Vincent

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Jan Blunck]

On Thu, Feb 16, 2017 at 2:36 PM, Konrad Rzeszutek Wilk
 wrote:
> On Thu, Feb 16, 2017 at 12:06:18PM +0100, Thomas Monjalon wrote:
>>
>> Any news about Xen dom0 status in DPDK?
>>
>> I think there is not enough interest for Xen dom0 in the DPDK community.
>> 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 (6 month ago) was to give more time for feedbacks:
>>   http://dpdk.org/ml/archives/dev/2016-July/044847.html
>>
>> 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.

FWIW I've also tested the 16.11 code in a Xen PV domU with uses the
xen_dom0 module due to the lack of hugepages.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Vincent JARDIN]

Le 16/02/2017 à 12:06, Thomas Monjalon a écrit :

The request (6 month ago) was to give more time for feedbacks:
http://dpdk.org/ml/archives/dev/2016-July/044847.html

Is it time now to officially remove Dom0 support?

yes

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Konrad Rzeszutek Wilk]

On Thu, Feb 16, 2017 at 12:06:18PM +0100, Thomas Monjalon wrote:
> 2016-11-11 04:49, Tan, Jianfeng:
> > Hi Thomas and Konrad,
> > 
> > On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote:
> > >> 2016-11-07 07:38, Jianfeng Tan:
> > >>> As some users are still using xen as the hypervisor, I suggest to
> > >>> continue support for xen in DPDK. And from 16.11, I will be the
> > >>> maintainer of all xen-related files.
> > >>>
> > >>> Signed-off-by: Jianfeng Tan 
> > >> Applied
> > >>
> > >> Please Jianfeng, could you start your new role by sending a status
> > >> of Xen dom0 support in DPDK? I think there are some issues in latest 
> > >> releases.
> > 
> > Yes, I'm on this. And hope to send out update in the next week.
> > 
> > > Pls also CC me and xen-de...@lists.xenproject.org if possible.
> > 
> > Glad to do that.
> > 
> > Thanks,
> > Jianfeng
> 
> Any news about Xen dom0 status in DPDK?
> 
> I think there is not enough interest for Xen dom0 in the DPDK community.
> 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 (6 month ago) was to give more time for feedbacks:
>   http://dpdk.org/ml/archives/dev/2016-July/044847.html
> 
> 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.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Thomas Monjalon]

2016-11-11 04:49, Tan, Jianfeng:
> Hi Thomas and Konrad,
> 
> On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote:
> >> 2016-11-07 07:38, Jianfeng Tan:
> >>> As some users are still using xen as the hypervisor, I suggest to
> >>> continue support for xen in DPDK. And from 16.11, I will be the
> >>> maintainer of all xen-related files.
> >>>
> >>> Signed-off-by: Jianfeng Tan 
> >> Applied
> >>
> >> Please Jianfeng, could you start your new role by sending a status
> >> of Xen dom0 support in DPDK? I think there are some issues in latest 
> >> releases.
> 
> Yes, I'm on this. And hope to send out update in the next week.
> 
> > Pls also CC me and xen-de...@lists.xenproject.org if possible.
> 
> Glad to do that.
> 
> Thanks,
> Jianfeng

Any news about Xen dom0 status in DPDK?

I think there is not enough interest for Xen dom0 in the DPDK community.
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 (6 month ago) was to give more time for feedbacks:
http://dpdk.org/ml/archives/dev/2016-July/044847.html

Is it time now to officially remove Dom0 support?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Tan, Jianfeng]

Hi Thomas and Konrad,


On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
 wrote:

2016-11-07 07:38, Jianfeng Tan:

As some users are still using xen as the hypervisor, I suggest to
continue support for xen in DPDK. And from 16.11, I will be the
maintainer of all xen-related files.

Signed-off-by: Jianfeng Tan 

Applied

Please Jianfeng, could you start your new role by sending a status
of Xen dom0 support in DPDK? I think there are some issues in latest releases.


Yes, I'm on this. And hope to send out update in the next week.




Pls also CC me and xen-de...@lists.xenproject.org if possible.


Glad to do that.

Thanks,
Jianfeng



Thanks!



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Konrad Rzeszutek Wilk]

On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
 wrote:
> 2016-11-07 07:38, Jianfeng Tan:
>> As some users are still using xen as the hypervisor, I suggest to
>> continue support for xen in DPDK. And from 16.11, I will be the
>> maintainer of all xen-related files.
>>
>> Signed-off-by: Jianfeng Tan 
>
> Applied
>
> Please Jianfeng, could you start your new role by sending a status
> of Xen dom0 support in DPDK? I think there are some issues in latest releases.
>

Pls also CC me and xen-de...@lists.xenproject.org if possible.

Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel