From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id CA7CE2BDF; Mon, 19 Jun 2017 15:22:27 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7A2D120BA8; Mon, 19 Jun 2017 09:22:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 19 Jun 2017 09:22:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=H3gpU7jShFu0jQR YpnnsAWZaDtWcJHYg9kYmz9GrJN8=; b=m3DOfnlI6Csel3oQKUG2l7pBoBDuB+E +WXejRCM/F3QKdoPjvMMj+apmPIYqPk4Q/DjyAZs8xBX9w9RBJaWIsLoY7KTZCwz 8u0dcY0SYTIJHSCy8KXCgkrm8Uy+kdIRa9m7yDQRZe3KQkWjnUnoxs+Elj9DyWMX DWkLGROrSmhc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=H3gpU7jShFu0jQRYpnnsAWZaDtWcJHYg9kYmz9GrJN8=; b=V9t6+MIl CsGUxNMpIlDuAW9/rRQMe6cHlYZjW7utTMI/ka0MQmd8E3IYHpKPRd0px4HATCU1 UDIMRvtKGbMR41fwmZIH2PW17n/y03vDt5FYlmwlHF3UQeYS/qAvh85GKPB8jZy8 ya67NG0Jzer2qitWzdZ87K79GAaiui8ff6jjkdJVXKt8cMEwpKbp2p03Xcl+bz6E y+r+CT9H5aE5mYBK6h0UL/vMGCMDIlZBJgtIzbdo6xtu+su/gX5/wSDCrl2+e/Yi 9XiFh0OyQsS4Sb6gVQ5hW9bHgyFNmjTm/Hqmc2byhDAFKpAH5CHh6K7icIg/hhLc DeJRxy7bnsMpPA== X-ME-Sender: X-Sasl-enc: tN86FmTkLQjhUQm8FwCXyygyJYDsgnk/iFHquwadkM+l 1497878547 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D80A24772; Mon, 19 Jun 2017 09:22:27 -0400 (EDT) From: Thomas Monjalon To: "Tan, Jianfeng" Cc: dev@dpdk.org, Joao Martins , Konrad Rzeszutek Wilk , Konrad Rzeszutek Wilk , Xen-devel , techboard@dpdk.org Date: Mon, 19 Jun 2017 15:22:26 +0200 Message-ID: <3259340.9y2bTrEvHo@xps> In-Reply-To: References: <1478504326-68105-1-git-send-email-jianfeng.tan@intel.com> <1596758.olymjc7Tvq@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] maintainers: claim responsability for xen X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 13:22:28 -0000 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