From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH 0/6] Xen DOM0 runtime support Date: Thu, 22 Oct 2015 23:28:58 -0700 Message-ID: <20151022232858.65498d27@xeon-e3> References: <1443487487-31915-1-git-send-email-stephen@networkplumber.org> <20150930103042.0672a078@urahara> <7433431.i8vU4GXoZ3@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Thomas Monjalon Return-path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by dpdk.org (Postfix) with ESMTP id B1861C384 for ; Fri, 23 Oct 2015 08:28:53 +0200 (CEST) Received: by pasz6 with SMTP id z6so109244211pas.2 for ; Thu, 22 Oct 2015 23:28:52 -0700 (PDT) In-Reply-To: <7433431.i8vU4GXoZ3@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 21 Oct 2015 16:40:08 +0200 Thomas Monjalon wrote: > 2015-09-30 10:30, Stephen Hemminger: > > On Wed, 30 Sep 2015 10:14:09 +0200 > > David Marchand wrote: > > > On Tue, Sep 29, 2015 at 2:44 AM, Stephen Hemminger < > > > stephen@networkplumber.org> wrote: > > > > It should be possible to build a single application or library > > > > that will work both in Xen and non-Xen environment. Any special > > > > case handling should be done at runtime. > > > > > > This patchset looks good, but can you go a step further and completely > > > remove the RTE_LIBRTE_XEN_DOM0 build option ? > > > This requires some more work (igb_uio, app/test), but I think this is worth > > > it all the more so as you are looking into it at the moment. > > > > I was thinking that for people on embedded systems having > > the build option (which stubs out support) was a good thing. > > No we must remove the config options. > It is not in a hot path so there is no reason to disable this support. > Please respin. I looked into this, But Xen dom0 is a driver as well, and DPDK as is makes all the drivers optional. Also, we don't use Xen dom0 directly (only the net-front driver), and therefore do not have the infrastructure to test that driver.