From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1FC49A056A; Thu, 11 Mar 2021 18:06:55 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E45BD16082A; Thu, 11 Mar 2021 18:06:54 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 72076406A3; Thu, 11 Mar 2021 18:06:53 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 19C6DED6; Thu, 11 Mar 2021 12:06:52 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 11 Mar 2021 12:06:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= 4Q/xYLzEHw3O+4srvFzL1qGCmrESxvEOWuTDPySHPaQ=; b=RbhdR610YyA/caAB PXEecrPKTj1qGqUo+qQ+huYRYlfuc9+LvJ80wUA7l0u2yne6CZPGMa+U2gKrDc48 MqilijyvLxuN+MdHFBZsZTLO4xV2ppShWFZk7usK6goTZfUE2YpmlUOEamtTGmnS ySf764GUClxGioVDtgJBS2EUi3tEVF4zS5cM8knIW6dtjKPBjumiga8jKlXnNZt8 WJi/JtXih0FAaAUDUyJzvf5Bn/6n3RXd/rpK7xAN1y33ibSo/OP/UWnG7EIlv3dn RHMqDiqI/eKlVDvD9VoEvgqKwJx/f/Beu1nDsp4uCvcdCr9hikbgcY92EWXege+D TAPnLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4Q/xYLzEHw3O+4srvFzL1qGCmrESxvEOWuTDPySHP aQ=; b=pn3+8pnPBsRj5TZBuiHRYkKKdNnwZpkVarpuYzZDVnOWUGNAY0bRdh2Sx 1P3JAvuoA7pX2ZYNFw34VSEZJXIjaiJRKQqQqTIbXGBtevYyqsjPQ6XPgi9kQSXT AJKT4x9K2lz75keFUvXO8sriSlC3wfU+Kp0mPt3ncMo2OgnQopHkhpjcV/RAhF+v y4wY4LqOPew9yriUoraBrwYRfGFK9QjDdjdVn9eBP9kB9lcN6jHsCXZJMQ3Bf5Gz snlW43ZZW9YQafThy0mVGxJ9Jmy3qKanN6QRRzrbivfL3lWN0xr/QPHy0zq38UNR 96GW/SHU9u2yu16DqE5rfm9kVAMXQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CFB271080063; Thu, 11 Mar 2021 12:06:50 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, techboard@dpdk.org Date: Thu, 11 Mar 2021 18:06:48 +0100 Message-ID: <2040842.lu7LhsAh0k@thomas> In-Reply-To: <20210311164530.GC1534@bricha3-MOBL.ger.corp.intel.com> References: <20210311151915.GA1534@bricha3-MOBL.ger.corp.intel.com> <20210311164014.GB1534@bricha3-MOBL.ger.corp.intel.com> <20210311164530.GC1534@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-techboard] RFC: DPDK drivers for DPDK bus types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 11/03/2021 17:45, Bruce Richardson: > On Thu, Mar 11, 2021 at 04:40:14PM +0000, Bruce Richardson wrote: > > On Thu, Mar 11, 2021 at 04:44:49PM +0100, Thomas Monjalon wrote: > > > 11/03/2021 16:19, Bruce Richardson: > > > > Hi all, > > > > > > > > looking for input here into the area of bus-type drivers and interaction > > > > with other drivers in DPDK. > > > > > > > > By way of context, I'm looking at extending the vdev support in the > > > > "raw/ioat" driver (file raw/ioat/idxd_vdev.c) to make it more user > > > > friendly. These devices are accessed by DPDK via nodes in /dev and > > > > paths in /sys, with the vdev parameters being passed identifying the > > > > particular devices to use. However, the presence of these devices can be > > > > detected at runtime by a scan of /dev and /sys, and so it's easy enough > > > > to implement a custom bus-type driver in DPDK to detect these, rather > > > > than having the user pass in vdev parameters (which can get awkward to > > > > use as the number of devices increases). > > > > > > I agree. vdev bus should be used for creating device from the void. > > > If the device has its roots in the system (HW or SW), there should be > > > a bus for that. > > > > > > > > > > However, looking through a few other drivers in the "bus" directory, it > > > > appears that scanning system paths, i.e. /sys, is fairly common, so I'm > > > > wondering if it's possible to have some sharing of functionality here. > > > > Unfortunately, the use of /sys in each of these drivers I've looked at > > > > seem sufficiently different to me that I've not immediately seen a > > > > common level of abstraction we can use. Therefore I'm looking for > > > > suggestions here that those in the community might have. > > > > > > Not sure it's worth looking for such sharing between bus. > > > > > > > > > > On a related note, I'm also concerned about the need for a single device > > > > type, e.g. one used by DPDK and shared with the kernel, to require two > > > > separate drivers to work together to support it - a bus driver for > > > > scanning and a type-specific driver for the actual functional > > > > implementation. Can we not find a way to reduce the number of drivers > > > > needing to be supported? > > > > > > The bus driver is managing the device life. > > > The device driver implements a functional class. > > > I don't see what to save. > > > Maybe you are biased because the rawdev class is fake. > > > > > > > The fact of the rawdev class being fake is irrelevant to this, the same > > would apply to any device class which as you say - "has it's roots in the > > system". However, for some of these devices, the roots in the system may > > well be unique, and therefore - irrespective of device class - one needs > > two separate drivers to work with such a device, a bus driver to do system > > scanning, and a device driver to manage the instances. > > > > > > > > > Following on from this, and if we can't find a good way of doing a > > > > generic driver for scanning /sys nodes, I wonder if there is value in > > > > providing a "generic" bus implementation in DPDK, as a catch-all for > > > > device drivers which need their own custom probing, but that do not > > > > neatly fall into the other types. The way this might work is to have the > > > > scanning and probing of devices left entirely to the device driver > > > > implementation itself. For example, rather than creating an idxd > > > > bus driver, it would be easier and more self-contained to have the > > > > rawdev driver itself able to perform scanning and probing - keeping the > > > > code all in one place. All the bus driver would have to do is maintain a > > > > list of drivers and found devices reported by the individual driver > > > > after they have done their own probing. > > > > > > So you mean there is a single user of the bus, > > > so the implementation could be moved into the device driver, > > > relying on a fake bus? > > > > > > > Exactly. If the bus exists for only one device instance - and will only > > ever exist for one device - why not allow the driver itself to have an > > extra function called "scan", rather than having to create a custom bus > > driver just to do that scanning. > > > > > > > > > Other possible candidates to think about that might be able to use > > > > their own probing from a generic bus might be, e.g. af_xdp driver, or a > > > > TAP or memif driver. > > > > > > These devices don't exist naturally in the system, so I think they should > > > be vdev. > > > > > AF_XDP devices certainly exist in the system, and serves at least as a good > > theoretical model of exactly what I am describing. Drivers for TAP or memif > > could be written to scan for and attach to already-existing instances on > > the system too. > > > > For the AF_XDP case, suppose that the kernel was extended to allow for > > certain queues to be marked or named, one could then create an AF_XDP bus > > driver to look for named queues on each NIC interface. Similarly a TAP bus > > device could scan for TAP instances previously created and configured and > > attach to them. The key thing is that in each case, the scanning done is > > unique and applies to only one net driver - nothing rawdev related about > > this! Therefore, while I don't think we would ever really implement bus > > drivers for these specific cases, they are examples which I think shows the > > value in having a bus type to allow generic scanning, rather than forcing a > > new bus driver to be created for each individual type of scanning > > necessary. > > > > Just to finally add that I'm happy enough to do a bus driver for the > specific case I'm looking at - it's actually far less work, I believe. > However, I'm just trying to avoid us having more components to maintain in > the future. I understand and I agree that creating a bus driver for scanning an item which will be ever managed by a single driver is meaningless. What you want is calling RTE_REGISTER_BUS() from the device driver. What else is needed?