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 4B40FA056A; Thu, 11 Mar 2021 16:44:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2CF2A22A555; Thu, 11 Mar 2021 16:44:57 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id 1CA7122A2FD; Thu, 11 Mar 2021 16:44:55 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A9C352877; Thu, 11 Mar 2021 10:44:53 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 11 Mar 2021 10:44:53 -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= kwgZ2Dg5sRik7ecDKPpomIyS/XPMdDhs0MxRfWKLI20=; b=YNXozPvfrD+1y0lK KRgKWVpFF18A1gkPtt6VI8pMU6GdhUCUn49NOur1dnCnkYno8SLw6B4rLdMTEai3 VaLE45xmtRLtsdID0+xO6R5SUDPLWcubdDUF+PB8QuLP6iX1QPB8uMotm6MYyJkp vubdgF7J+QyDywu/Ah7moLLkrhBxAQbsg9Xt8oRTW6O+w/yJO/7sj2Po+1Ma3O+T e+hguT7ktLGJ5e7hlmZAL2CbuCwNiDdA42236bi5BwS5CdUIPEljl0JJSlY3gwIo 1n5LNLfnUuei5Ixw6BF9zq27SbVeny7d1qNZAK864R+6RqSdhDaOphzQc+9g+qNR EQ7DnA== 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=kwgZ2Dg5sRik7ecDKPpomIyS/XPMdDhs0MxRfWKLI 20=; b=bfTFLj3J6wHRKReh2qofz2DEGaKoKGSQAaqsSu7A6WSY7nZ4aE32FWp0g Iq59m74v32jtnkrxYskvOe0Ftg0KURwf/YMC4KSUtdK6+cY6N87qCVXb+JHeZZK4 EOuEc2db3+qVcpHlKi86AVFCyo5v5wdSYcxNIqVmROnGf8yVOuv+hU9SDW7n4udR 4KqCpQAY7RnSj3elBe1cxc4P6euldKHZVVlx7WVJIqEX0DwQ2xmrKVWFI6+TQ3wG IrZwI78hr7cvKBe0IqBfGDerawSD/3NaMn49drNHMYNsk+bG5GvPhjTbCQ0+XWkr ZAlNOKaiXy+K2HODhOlNxcsfUoRcA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddgkeduucetufdoteggodetrfdotf 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 842AF1080064; Thu, 11 Mar 2021 10:44:52 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, techboard@dpdk.org Date: Thu, 11 Mar 2021 16:44:49 +0100 Message-ID: <5689393.EOBcx09PAn@thomas> In-Reply-To: <20210311151915.GA1534@bricha3-MOBL.ger.corp.intel.com> References: <20210311151915.GA1534@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 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. > 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? > 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.