From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) by dpdk.org (Postfix) with ESMTP id 95CC356AB for ; Sat, 2 Jan 2016 19:01:35 +0100 (CET) Received: by mail-pf0-f173.google.com with SMTP id 78so181477285pfw.2 for ; Sat, 02 Jan 2016 10:01:35 -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=YGjaQsdXqHqb1GmfGQqofYZ4FwF4p4KxqRFXBt9cVe8=; b=YXnfRl4BoYPZM3ULbHM4tKCKyQxkjC7DXfKUWMEM8oLy61Q3BxTPlhiaqJ0K2lQMSS GpR8Yr8gbPcOT/iCq3ORjnhpSEy5LjQyeSSQ9f1YbeFqQETen5895GQjgxXdBY29fEVF gLsGvBDUGU2igoIGDwYJid9zlqNzf1uZi4z4Aq+43VfI/d4IGS72k9v2oInaX4OIqi1L 17LNCv479M/9uD7OHBjVqP7eKKXys5gmN7aRBR0Sen2qYEd7VNs4YwBj7Je9bVGRFpSV CtAjFCkjOfrT8ywRC9KoJL1OYho9ShqNoUVxeO8dCVj8ZWHSRrgb7B8/rsitEYQed6rV 5VqQ== 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=YGjaQsdXqHqb1GmfGQqofYZ4FwF4p4KxqRFXBt9cVe8=; b=laJNosdjry6NO+GKnHn6vJY7bJ8F8gBZWoWhCAgKyLHcitVCBGzcCg2BvXSIkGUbnq UVV7WYYKPKwV/Srl9HyRYxyvYPlx6vuY3HiV+cEZwO+MhZTHViRpHP85dvuAU1c/ah1j k8apAptxpA3Z1WORdVby2Y+kWK1PQWy9Nv7VsPoiXT+ctbVMGW1e7V86rGSkUAfbFYhq rVN44h9yTqrEXIzHXY59tpIf7RBAzwl5ln6xwmrdzBhw+XCWkDrAaXT+ToSBw3QFjCN6 smiwbAM+V+lnVTwhPrqkEgjBcSULl3VvsEnWKXPP1tdcnIoaz+XUjQDF6uXvO4Uign8N t2Fw== X-Gm-Message-State: ALoCoQntiVTn4SUrlKUOjBIevUj4Sdm6ettUD5EEXy/2kpYDC49RQUnPyTZFpJdG8S1MM+LkWsbj/zAQl96mW19r6ESVOyGAig== X-Received: by 10.98.65.219 with SMTP id g88mr100483185pfd.63.1451757694815; Sat, 02 Jan 2016 10:01:34 -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 ux2sm115228584pac.46.2016.01.02.10.01.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2016 10:01:34 -0800 (PST) Date: Sat, 2 Jan 2016 10:01:44 -0800 From: Stephen Hemminger To: Jan Viktorin Message-ID: <20160102100144.5e87e98b@xeon-e3> In-Reply-To: <1451682326-5834-2-git-send-email-viktorin@rehivetech.com> References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1451682326-5834-2-git-send-email-viktorin@rehivetech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 18:01:36 -0000 On Fri, 1 Jan 2016 22:05:20 +0100 Jan Viktorin wrote: > Introduce the interface to SoC device infrastructure. A SoC device > here means a device integrated on the chip via a (simple) bus > that lacks of auto-discovery and other properties which are common > for PCI. A counterpart in the Linux Kernel would be a platform_device > (but this is not necessarily 1:1 mapping). > > Systems without auto-discovery properties are described by a (Flat) > Device Tree. Device Tree is usually available on embedded systems > in /proc/device-tree. Every device has a unique path in the Device > Tree and so it identifies every such device. This path is used > to identify a device in rte_soc_addr. > > Binding of drivers to devices in the Linux Kernel is often done > by matching the compatible entry in the Device Tree. As there is > no standard/generic way to read information like vendor, model, etc. > from each SoC device, we match devices by the compatible entry too. > The rte_soc_id contains an array of compatible strings telling what > each device is compatible with. > > There are no DPDK-specific OS drivers for SoC devices at the moment > and unfortunately we cannot use the PCI-related ones as they contain > too much PCI-specific logic. > > Whitelisting and blacklisting of devices is based on the Device Tree > identifier (rte_soc_addr) to mimic the PCI behaviour. > > Signed-off-by: Jan Viktorin 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?? On a pratical level, the new SoC support must be optional (via DPDK config infrastructure), since most architectures won't be using it. In most cases, it is better from usability if everything is runtime based, but with SoC this is a platform/architecture configuration. Do you consider this will break binary compatibility since sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the union inside rte_devargs are much smaller (like 32 bytes).