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 E2A7DA056A; Thu, 11 Mar 2021 16:19:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C438622A542; Thu, 11 Mar 2021 16:19:22 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 5E64122A4D6; Thu, 11 Mar 2021 16:19:21 +0100 (CET) IronPort-SDR: 4VueFXEeaxrg8EInjTqAgSHvJEdYnO35OhOB+jDBG6S9UGhl59qFD6lyQ99Ia2sdVvxo7RDPA7 9VMIxrDwZH6g== X-IronPort-AV: E=McAfee;i="6000,8403,9920"; a="188777940" X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208";a="188777940" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2021 07:19:19 -0800 IronPort-SDR: K4pHXxqhO3NM0m0s4SKjfcIxLeuEZknIGpeHw3XoSTpaIUGn72vbJfXi+eZjI1rOSkpl8V/f3i VvAkgy+eeg8w== X-IronPort-AV: E=Sophos;i="5.81,240,1610438400"; d="scan'208";a="404101196" 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 07:19:18 -0800 Date: Thu, 11 Mar 2021 15:19:15 +0000 From: Bruce Richardson To: dev@dpdk.org, techboard@dpdk.org Message-ID: <20210311151915.GA1534@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dpdk-dev] 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" 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). 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. 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? 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. 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. Thoughts and inputs please? Regards, /Bruce