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 4142FA0540; Tue, 8 Nov 2022 09:56:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CE3E8410EA; Tue, 8 Nov 2022 09:56:37 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id D1CDE4003C for ; Tue, 8 Nov 2022 09:56:35 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 814095C01F6; Tue, 8 Nov 2022 03:56:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 08 Nov 2022 03:56:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1667897794; x= 1667984194; bh=8S23i+8jA9Qa6RAcUSRdgYWAAzuIEw4NYiVi+gUpvXg=; b=A 3ve26EioW23CV1cw0T9n8wi3gCiaAZ8/F7zLtj4dyHEz/l7D7QB4eRuX/5mqjPFt Dg604OHdU/0X/XwQvEnhSBWSU9QuX4VgDkEh5up3AluslAMooHxHyBuF25VzAYtD Z0RDCxrbHTAfd5NB1Znzx/SkVsZKi6RjWOiqDf2cL28Ku0dIhP9BjLSnC+k78Isb I0uhg3HjM4HeClLlAxojJR+U7+1nQYCsQ30F4dYv0oc/7F4SvKMZVJJXni02GwCp DAu/ZqnNrZ0Vm42SAEb0YOuEN/4a2esQPx8G1sgAXi7WcGG0Zw7dCEmgva2yRyM2 5hWMRH4qmBDkJddwDQcKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1667897794; x= 1667984194; bh=8S23i+8jA9Qa6RAcUSRdgYWAAzuIEw4NYiVi+gUpvXg=; b=j fUFuwnkQ4kOT01ukk0FCirh6q4R/Lc/aYUd21abTYfcFPabeHhPJXkC5PbpHG5BQ YA7ngyqGidH4YbNGlpycnNAlVOkHWOrMCukR0pBijHbFqIwCGKGF/pOFyqkP2yxi Y7R2GEugR2viz9iNc+SUCK/KQePsnhzwi2n0mD2PoT0mcddbHdxEw9Exqy8DXmYS r3T7m1VBk8ZrFjsISWqE8aQrhlXc6dtYkNVVh4UNpvUGsDbl9+JoFXQQwRZ/5cPd K87OCzeYSiTDI4gxzVkGso9cCVxi7cVOq79Prwpng8NCdiycpFR2nyhHhuj2kgQe iBgVbhE//bjPYXmDVXU4A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvdelgdduvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Nov 2022 03:56:32 -0500 (EST) From: Thomas Monjalon To: "Chautru, Nicolas" Cc: "dev@dpdk.org" , "gakhil@marvell.com" , "maxime.coquelin@redhat.com" , "trix@redhat.com" , "Richardson, Bruce" , "hemant.agrawal@nxp.com" , "david.marchand@redhat.com" , "stephen@networkplumber.org" , "Vargas, Hernan" Subject: Re: [PATCH v12 04/16] baseband/acc: introduce PMD for ACC200 Date: Tue, 08 Nov 2022 09:56:30 +0100 Message-ID: <2823585.NACDBdzCOe@thomas> In-Reply-To: References: <20221012175930.7560-1-nicolas.chautru@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 08/11/2022 00:52, Chautru, Nicolas: > Hi Thomas, > Reminder : do you mind kindly clarifying/confirming below. Then we can update the docs accordingly. Thanks. > > From: Chautru, Nicolas > > From: Thomas Monjalon > > > 31/10/2022 16:43, Chautru, Nicolas: > > > > From: Thomas Monjalon > > > > > 12/10/2022 19:59, Nicolas Chautru: > > > > > > +Bind PF UIO driver(s) > > > > > > +~~~~~~~~~~~~~~~~~~~~~ > > > > > > + > > > > > > +Install the DPDK igb_uio driver, bind it with the PF PCI device > > > > > > +ID and use ``lspci`` to confirm the PF device is under use by > > > > > > +``igb_uio`` DPDK > > > > > UIO driver. > > > > > > > > > > igb_uio is not recommended. > > > > > Please focus on VFIO first. > > > > > > > > > > > +The igb_uio driver may be bound to the PF PCI device using one > > > > > > +of two methods for ACC200: > > > > > > + > > > > > > + > > > > > > +1. PCI functions (physical or virtual, depending on the use > > > > > > +case) can be bound to the UIO driver by repeating this command > > > > > > +for every > > > function. > > > > > > + > > > > > > +.. code-block:: console > > > > > > + > > > > > > + cd insmod ./build/kmod/igb_uio.ko > > > > > > + echo "8086 57c0" > /sys/bus/pci/drivers/igb_uio/new_id > > > > > > + lspci -vd8086:57c0 > > > > > > + > > > > > > + > > > > > > +2. Another way to bind PF with DPDK UIO driver is by using the > > > > > > +``dpdk-devbind.py`` tool > > > > > > + > > > > > > +.. code-block:: console > > > > > > + > > > > > > + cd ./usertools/dpdk-devbind.py -b > > > > > > + igb_uio 0000:f7:00.0 > > > > > > + > > > > > > +where the PCI device ID (example: 0000:f7:00.0) is obtained > > > > > > +using lspci -vd8086:57c0 > > > > > > > > > > This binding is not specific to the driver. > > > > > It would be better to refer to the Linux guide instead of > > > > > duplicating it again and again. > > > > > > > > > > > +In a similar way the PF may be bound with vfio-pci as any PCIe device. > > > > > > > > > > You could mention igb_uio here. > > > > > Is there any advantage in using igb_uio? > > > > > > > > > > > > > Igb_uio is arguably easier to use to new user tend to start with it > > > > or specific > > > ecosystem. This is typically the entry point (no iommu, no flr below > > > the bonnet, no vfio token...) hence good to have a bit of handholding > > > with a couple of lines capturing how to easily run a few tests. I > > > don't believe this is too redundant to have these few lines compared > > > to the help in bring to the user not having to double guess their steps. > > > > More generally there are a number of module drivers combinations > > > > that are > > > supported based on different deployments. We don't document in too > > > much details for the details since that is not too ACC specific and > > > there is more documentation no pf_bb_config repo for using the PMD from > > the VF.. > > > > > > > > Basically Thomas let us know more explicitly what you are suggesting > > > > as > > > documentation update. You just want more emphasis on vfio-pci flow > > > (which is fair, some of it documented on pf_bb_config including the > > > vfio token passing but we can reproduce here as well) or something else? > > > > > > There are 2 things to change: > > > 1/ igb_uio is going to be deprecated, so we must emphasize on VFIO > > > > Is there a date for deprecation? Do you mean to EOL the dpdk-kmods > > repository itself; or something more specific for DPDK code like removing > > RTE_PCI_KDRV_IGB_UIO; or last to just take out from documentation? There is no final decision yet, but the techboard wishes we focus more on VFIO which is in Linux upstream. Out-of-tree module (like igb_uio) is not recommended. > > It tends to be historical but uio has value notably for ease of use. I don't think it is easy to use an out-of-tree module. It needs to be compiled and installed. > > 2/ for doc > > > maintenance, it is better to have common steps described in one place. > > > If needed, you can change the common doc and refer to it. > > > > Do you mean to remove these sections and just add a pointer to > > https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html instead in all these > > bbdev PMDS? Yes If the Linux guide is not convenient, I suggest to improve it. > > Please kindly confirm. I see specific steps for binding in many other PMDs docs > > in DPDK, a bit redundant but provides simple steps specific to a PMD in one > > place. I don't mind either way. The other PMD docs should point to a common doc. Redundant docs make very hard to update.