From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by dpdk.org (Postfix) with ESMTP id 81CEC2C50 for ; Mon, 20 Feb 2017 18:32:58 +0100 (CET) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1KHWtk4031938 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Feb 2017 17:32:55 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v1KHWtSt012687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Feb 2017 17:32:55 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v1KHWsc2015932; Mon, 20 Feb 2017 17:32:54 GMT Received: from [192.168.1.66] (/89.114.92.174) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Feb 2017 09:32:53 -0800 To: Jan Blunck , Konrad Rzeszutek Wilk References: <1478504326-68105-1-git-send-email-jianfeng.tan@intel.com> <83319780-26e9-afb6-74cd-20c07dad04a7@intel.com> <1915354.hxpEe7tUeI@xps13> <20170216133657.GB14695@dhcp-whq-twvpn-1-vpnpool-10-159-157-38.vpn.oracle.com> <20170217160731.GA30539@char.us.ORACLE.com> Cc: Vincent JARDIN , Thomas Monjalon , "Tan, Jianfeng" , Konrad Rzeszutek Wilk , dev , Bruce Richardson , Yuanhan Liu , Xen-devel From: Joao Martins Message-ID: <58AB2903.2080402@oracle.com> Date: Mon, 20 Feb 2017 17:36:03 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Source-IP: userv0021.oracle.com [156.151.31.71] 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, 20 Feb 2017 17:32:58 -0000 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