From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by dpdk.org (Postfix) with ESMTP id A5EF15A0A for ; Sat, 2 Jan 2016 20:13:57 +0100 (CET) Received: by mail-pa0-f42.google.com with SMTP id do7so538504pab.2 for ; Sat, 02 Jan 2016 11:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=HcwlgaOGJPKLhn8gq69CXXlz9ajw1ea6VVT5snERvzY=; b=YDndISc7YP6ox1p4SFLq/In+0rZKKvbd3mXpHXabdIRBYHbOQGKDTYnAJstyjE7hhd O6D6+KIs+4nxxJ62HMg8afAjvxmZJIPOCnsYHZftJKBBYy0FwcYn/wjQPjlPc+C6D8aE RLkQ81Xe/KxnCLIMyDeziFTV9+GTowpaElzdhsETV9XbbJ3aH1Ac8v4h65vGWPOiz1o6 xbwM7hpZpxJ3SzlHc/hBTbPUPq11HoNTwxwSDAKuhH4dZlABWRlE+gOW/hONFhAIKW3R 25KyVb++SIVSz/U44vGVgD03cMQateZV0iRG+XBT1EorpIRLi3m596kqD6jrEbd/M88h O6hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=HcwlgaOGJPKLhn8gq69CXXlz9ajw1ea6VVT5snERvzY=; b=cW6khXddLTCRh6UYrTE68k/6fFZVAUzwnRgUqs2Utbx9k3126F38kxbiHY9uHKwObZ 9HJy2F2mz/hCZ+zn/AN/SaEqD+gC8dHTfqilUttM+c2kmJhoPABCqy6QSiHtFU8QCiGB 96VnWd+wV9FE4um31go9lnP3r3GTLu82H1Ylc+XcJV1k4z5sI4FGgRAOt3DCxWZpKOpy iRPIvSDtAfrFz6rNR04AoHgUzh6ai0dyXhX8cfb6sKpp9YsZVWFfR7XPCX1bVBb6iLwQ 5M60LdbBGYigLCfXyRSiuLguUSsn0q3Mvs0jKyYHMdkP7Tdb10EWqWaJqD/eN9g6Rh1f IDsw== X-Gm-Message-State: ALoCoQmcDHwPNDDLaVJsbwiArFC/TbVE9roIZQDzqqa8EJ1TLXnE2ZLNgBCaymxpuNQuWxJ3s790kPnnjqip4NE8JtNQ4zRLlg== X-Received: by 10.66.65.203 with SMTP id z11mr115982145pas.152.1451762037060; Sat, 02 Jan 2016 11:13:57 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id lq10sm32310276pab.36.2016.01.02.11.13.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2016 11:13:56 -0800 (PST) Date: Sat, 2 Jan 2016 11:14:03 -0800 From: Stephen Hemminger To: Jan Viktorin Message-ID: <20160102111403.1389b983@xeon-e3> In-Reply-To: <20160102195216.4b660495@jvn> References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1451682326-5834-2-git-send-email-viktorin@rehivetech.com> <20160102100144.5e87e98b@xeon-e3> <0CC8CFBE-CFA0-4BCA-B09D-6287801C406F@intel.com> <20160102195216.4b660495@jvn> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 19:13:58 -0000 On Sat, 2 Jan 2016 19:52:16 +0100 Jan Viktorin wrote: > On Sat, 2 Jan 2016 18:35:08 +0000 > "Wiles, Keith" wrote: >=20 > > >Yes, DPDK needs to work in embedded environments with device tree. > > >Would it be possible reimplement device tree parsing in user space? > > >Ideally with a shared code from kernel?? =20 > >=20 > > Stephen, Do you mean we have to add kernel code to support DPDK on SoC = Platforms? If that is the case I would like to not require code be added to= the kernel to support DPDK. >=20 > We will need a kernel module. But this is not necessarily related to the > device-tree parsing. >=20 > > > > > >On a pratical level, the new SoC support must be optional > > >(via DPDK config infrastructure), since most architectures won't be us= ing it. > > >In most cases, it is better from usability if everything is runtime ba= sed, > > >but with SoC this is a platform/architecture configuration. =20 > >=20 > > I am not sure I agree with the optional support, as it could be stated = that PCI support is optional on SoC platforms. It would be best to not trea= t SoC support as special compared to PCI support. Other then extra footprin= t it does not seem reasonable to require SoC support to be ifdef=E2=80=99ed= in the code. Plus adding more ifdefs is not a good testing solution. >=20 > This is a matter of preserving ABI. Turning PCI-support to be optional > seems to be a difficult step at the moment. >=20 > >=20 > > Can we detect somehow we are on a system with SoC support or even a sys= tem that supports PCI for that matter? >=20 > IMO, we can detect two things: "PCI is present on the system" and > "Device tree is accessible in /proc/device-tree". Is this acceptable? >=20 I am just as concerned with building and having useless code. For now most environments can just use PCI, and having to carry around dead code seems wasteful and potential for some security abuse as well.