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 8D639A056A; Thu, 11 Mar 2021 17:45:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4082616080E; Thu, 11 Mar 2021 17:45:39 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 38D17406A3; Thu, 11 Mar 2021 17:45:37 +0100 (CET) IronPort-SDR: ERpHEK8d9hgurL6CmNgTi0+htBrHsqr+fB/nrRvTwiuXFbVi7kp7Ue8VqZziQ5uhsAnY7xz3iM BmtGf+auICsw== X-IronPort-AV: E=McAfee;i="6000,8403,9920"; a="188062694" X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208";a="188062694" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2021 08:45:34 -0800 IronPort-SDR: n1jlcM5LpAJOyhzcVsw+xHSSZBpKYf04RpWVE7rVzrxkV+AoiWRc30RI1tK2E7HDDZMM4i28Sy 8WAKaYDcCb8A== X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208";a="404126676" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.23.238]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 11 Mar 2021 08:45:33 -0800 Date: Thu, 11 Mar 2021 16:45:30 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org, techboard@dpdk.org Message-ID: <20210311164530.GC1534@bricha3-MOBL.ger.corp.intel.com> References: <20210311151915.GA1534@bricha3-MOBL.ger.corp.intel.com> <5689393.EOBcx09PAn@thomas> <20210311164014.GB1534@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210311164014.GB1534@bricha3-MOBL.ger.corp.intel.com> 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" 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. /Bruce