From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0077.outbound.protection.outlook.com [104.47.1.77]) by dpdk.org (Postfix) with ESMTP id 84E00E07 for ; Sun, 18 Sep 2016 11:41:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X9VvgK1yGKwkVO2jKy56alG3iDQyJPP1VrNIrQffpJo=; b=AjO0gUpj/RFxmQ4YLeyyQ0P1+qNgvfV80Er0HuHqrv7+Cw0w4hCRB0lV1U/4qyNBKupphBPgGZ6WNaM6XCOCBHBXsZiH0z4rBhTvWl742iGk6tkMeyWGBvCsE+G0tszB9JxdZHnU2oaxkWjlurGKoT0TtM4IWVdPfIyFlWJMM/0= Received: from HE1PR04MB1612.eurprd04.prod.outlook.com (10.164.48.150) by VI1PR0401MB2061.eurprd04.prod.outlook.com (10.166.141.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.2; Sun, 18 Sep 2016 09:41:56 +0000 Received: from HE1PR04MB1612.eurprd04.prod.outlook.com ([10.164.48.150]) by HE1PR04MB1612.eurprd04.prod.outlook.com ([10.164.48.150]) with mapi id 15.01.0639.005; Sun, 18 Sep 2016 09:41:56 +0000 From: Hemant Agrawal To: Jan Viktorin , Jianbo Liu CC: Shreyansh Jain , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL Thread-Index: AQHSCnZNOe1dWErAqUG5eKrnWordPaB+zocAgAAXVQCAABpsAIAABcEAgAAFu2A= Date: Sun, 18 Sep 2016 09:41:55 +0000 Message-ID: References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1473410639-10367-1-git-send-email-shreyansh.jain@nxp.com> <20160918092220.062b95bf@jvn> <20160918111730.1cc74b74@jvn> In-Reply-To: <20160918111730.1cc74b74@jvn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hemant.agrawal@nxp.com; x-originating-ip: [122.162.217.127] x-ms-office365-filtering-correlation-id: 3bc3c7e5-0b79-4c56-a59e-08d3dfa8076c x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2061; 6:vrqKJfUYHfiQfLHrh2ljfZl+t8bQ3RD5O3em1KOrM3dloUfMq/1Oz+yaDsRP2DTOcpqO/vPWqfFQRsmUqRz52q/igLhUQ9WrICNEh7Q/9Cf79c/F9i/SxBCLCVhb13MWKXrtocUVQDHcOhTAHyGnPBQ7aJe0s3qk/9RbWNKQQ93bkVJcIFNj3Ywwm3UslgIvjRjQkSht+MO9ARwCOE8nzFGNVWnixm6I7Og2DArpBHJm3vLecTA540S4mmFf0ohXFPdiSk5/JEUVH+8xEjy2hV+HqC03iC5oh380cL8ft7jfhk3oZovkPlvpQmqDNEbIyY33MTl3ptW5wG3yz4VXrw==; 5:kQ01DcL7EG+NYSkgvww1sPvHNzygHbLKNfXVfRY1sshdA4uXmViJgy0Ty+o44IJcATCtJyPTuPSBcLATmxdEnlmdDaqYUbfI27uiMiRIJliw67LqvENqxPcjRLIAFaPqdGEU5FOfPrX7+QqCiXfaaQ==; 24:tvdsQ3PSgazJHPjUWa7QkDt0pzwo1UiUZuuXJGkAdEwf/3lNdiIqM+WXrr804K85l4tIqT6LSYM52RNwpUyq+3pmAtydK+WInfF7o3BViUs=; 7:z28IJSFWalvXiTag99BXlHSTOXXqySaC1VkexlYPG0B79mWiaDIxUhAruQUfmi0MRfsOrAdncivL/JKsLVwpDphmTUBEd6Ntgoe7M82dY9HyJxwKknHlD5iihnpwLk0oaepObD53gV6j4YFKhStTiqBq6uQQp9hRP2jJjSqmCZ+zWaqAtBe+XtsEy7ewCOPOcJ5IzAVRn+5PWgkcn/E2LTZsk2E/ONreBMmseGUm7sEOXvQj9iDhPWh6QKmtDP/JyvZKaiwFMUfja5lj4lrFHFX31y/wQEDvG8jwnorSUNTQRkDZUWhJzXYXsTACIJMZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2061; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(185117386973197); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:VI1PR0401MB2061; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2061; x-forefront-prvs: 0069246B74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(13464003)(252514010)(24454002)(8676002)(81156014)(2906002)(81166006)(3660700001)(3280700002)(33656002)(77096005)(561944003)(8936002)(2900100001)(2950100001)(87936001)(189998001)(66066001)(11100500001)(5001770100001)(97736004)(68736007)(3846002)(102836003)(6116002)(4326007)(586003)(7846002)(86362001)(7736002)(93886004)(15974865002)(19580405001)(305945005)(7696004)(19580395003)(76176999)(54356999)(5002640100001)(101416001)(92566002)(50986999)(74316002)(9686002)(106116001)(122556002)(106356001)(105586002)(5660300001)(10400500002)(76576001)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2061; H:HE1PR04MB1612.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2016 09:41:55.9450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2061 Subject: Re: [dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL 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: Sun, 18 Sep 2016 09:41:58 -0000 > -----Original Message----- > From: Jan Viktorin [mailto:viktorin@rehivetech.com] > On Sun, 18 Sep 2016 16:56:54 +0800 > Jianbo Liu wrote: >=20 > > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > > On Sun, 18 Sep 2016 13:58:50 +0800 > > > Jianbo Liu wrote: > > > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > >> > Introduction: > > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> > > > >> > This patch set is direct derivative of Jan's original series [1],[= 2]. > > >> > > > >> > - As this deviates substantially from original series, if need be= I can > > >> > post it as a separate patch rather than v2. Please suggest. > > >> > - Also, there are comments on original v1 ([4]) which are _not_ > > >> > incorporated in this series as they refer to section no more in= new > > >> > version. > > >> > - This v3 version is based on the rte_driver/device patchset v9 [= 10]. > > >> > That series introduced device structures (rte_driver/rte_device= ) > > >> > generalizing devices into PCI, VDEV, XXX. For the purpose of th= is > > >> > patchset, XXX=3D>SOC. > > > > > > [...] > > > > > >> > > > >> > 5) Design considerations that are different from PCI: > > >> > - Each driver implements its own scan and match function. PCI use= s the > BDF > > >> > format to read the device from sysfs, but this _may_not_ be a c= ase for a > > >> > SoC ethernet device. > > >> > =3D This is an important change from initial proposal by Jan in= [2]. Unlike > > >> > his attempt to use /sys/bus/platform, this patch relies on the > > >> > PMD to > > >> > > >> It could be many redundant code if Each PMD driver has the scan > > >> function if its own. > > >> I think Jan's implementation is common to many platform drivers. > > > > > > I personally can find a use case for having a custom scan function. > > > However, we should at least provide a default implementation. > > > Probably, both the scan and match functions should be used to > > > _override_ a default behaviour. So, only drivers that require to > > > scan devices in a specific way would provide a custom function for th= is. > > > > > And for each platform/product.... > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > approaches. I'd like more to provide one or more scan > > > implementations in EAL and do not put this responsibility on PMDs. [Hemant] A common/default scan function can be added, provided at least o= ne or more PMD driver support it.=20 w.r.t Jan's original scan function, it was not suitable for any of the NXP = SoC's whether ARM or PowerPC. Unable to validate the Jan's scan function on a real platform, we have skip= ped it for next phase. =20 Addition of a default scan function can only be done in next phase, when we= find a suitable SoC PMD driver supporting it. > > > > > >> > > >> > detect the devices. This is because SoC may require specific or > > >> > additional info for device detection. Further, SoC may have > > >> > embedded > > > > > > Can you provide an example for "additional info for device detection"= ? > > > > > >> > > >> Can you give us more precise definition about SoC driver? Does it > > >> include the driver in ARM server? > > > > > > I am sorry but I don't understand this question. > > > > > > What you mean by a "driver in ARM server"? Do you mean a kernel drive= r? > > > > > > There is no "SoC driver" in the text so what definition are asking fo= r? > > > > > This patchset introduces rte_soc_driver, which is inheriting from rte_d= river. > > I want to know what devices can use this SoC driver/device framework. > > Is it for the devices from ARM servers, or embedded systems of > > different vendors? >=20 > First, this is not an ARM-specific feature. Consider any MAC connected to= the > processor via some on-chip bus. In the world of ARM, it is usually a kind= of > AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM examp= le. > Here they provide the Quick Path bus (but I don't know the details). So, = you > cannot access such device as PCI. It is usually not possible to distingui= sh the bus > type easily (Linux calls this a platform device). >=20 > So, an rte_soc_device denotes a device integrated on the chip (SoC, Syste= m-on- > Chip). Such devices can have a lower access latency because they are clos= er to > the processor. >=20 > So, if you have a server system driver by a SoC with integrated MACs (no = PCI-E > involved), there is no way how to access them from DPDK. An rte_soc_devic= e > represents such devices and provides a way how to access them from DPDK. > That is the goal... >=20 > You can have an embedded device (router, switch, monitoring device, NAT, > firewall, anything in a "small box" with high throughput demands) that pe= rfectly > fits into this SoC framework because it would be usually based on some So= C > (ARM, ARM64, ...). >=20 > > And this framework is too generalized, if we don't try to understand > > "soc" in rte_soc_driver, we can use it for PCI devices. :) >=20 > No, you cannot use it for PCI devices, don't worry. There should be no PC= I > facilities like access to BARs :). But, I think I got your point. >=20 > It seems to be generalized because there is no real standard in this area= . Any > vendor of SoC can provide her custom on-chip bus. The original idea was t= o build > on top of the platform_device from Linux which hides this information fro= m you > (unless there is some bus-specific DMA which we must handle in the DPDK P= MD). >=20 [Hemant] Agree with Jan's comments.=20 This "SoC" term is coined to differentiate the non-PCI based devices. It = is not specific to ARM or embedded systems.=20 So, now we have two categories of device drivers,=20 - one which can be represented by standard PCI device framework;=20 - others, which does not fit into PCI devices model.=20 The framework has to be generic to accommodate different types of drivers, = as there is no "standard" driver model for SoCs. > We could provide an rte_amba_device instead but there is no advantage in = this. > The amba bus is defined on the RTL level and not on the software level (n= o BARs, > no device discovery). And there are other buses working in a similar way. >=20 > > > > Thanks! > > Jianbo >=20 Thanks [Hemant]=20 >=20 >=20 > -- > Jan Viktorin E-mail: Viktorin@RehiveTech.com > System Architect Web: www.RehiveTech.com > RehiveTech > Brno, Czech Republic