From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by dpdk.org (Postfix) with ESMTP id 113CC1B143 for ; Thu, 18 Oct 2018 18:41:43 +0200 (CEST) Received: by mail-ed1-f65.google.com with SMTP id z21-v6so28840273edb.11 for ; Thu, 18 Oct 2018 09:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bo/FjucXQ+6PU28BYDdH7Fzv97xd0ZgOkt8XPJW0USs=; b=gfHcSkZF1/zobX1MuNcbqDfmgEPayWN5cfN/iF8cOHQ0bYy9sIGzcJdnbhPUcg6RzC CHkxv5JSqhBadNr70gCok2C2mObGBgHrforgmic5CkIgX9ArfDTN/VYoMJ6F3fr/Tsq8 SpQuJjad7uXGSD2VMrva7FFO6JaOTmRacBkHjfx2HOUhAbSQSqDOPHevx7mDLREtnW+k llyMvoX8LT2NhujXzXOR6hF+MG5XCqrTQLxWBBkmvknQZ0uS/5rTiiFLBRcNssE37Np/ SJla/POBUu/mB/IL+03bCJMy4Oq3d9o/bztRmZWXz6iAWMSsm1zlSF5ob/tjRQAvihYy k6fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bo/FjucXQ+6PU28BYDdH7Fzv97xd0ZgOkt8XPJW0USs=; b=OrizDrwF/Nj1Y4P3weTJVq/F6vpdrBAZWbEknxPcXSPKLem3+e3oNYbG9u3MtBPDWW zKVC/9LGAuNCI0PaqWQqzr1vGeVquJ1vTSxn4jNsgYvOIWbqU+5QNhb/Zf/7r/9cASOG jB3nfNUdmVU0j8li357Le8fjtjbuSAcbTAih7DykSfXjS90cIhPq6RNa8FvU9CLOu/ag 1/ZfUHpE3GcMePG18k4JViBgfZely/7l9UWn+GY8dl9Pds/bvOg6RH9wwvSwLMLS3pR3 NL1k74mABz/jsa8khU209fKoTBH98GAsjqw+7pJHTk9xWHKWFHzM9QqI62SZX11cBI0u 7Llg== X-Gm-Message-State: ABuFfohrfwFsvoV7hE8nxW3a7gEtRMYEFBWCM0prJE9+99tZE7/wY97/ 6Ly2iqHK0mEYplheadtsCaEpev33gm+96b1KbNNHJA== X-Google-Smtp-Source: ACcGV61SWnsAiOcZavGc+ciFDz2/pW4AaV5oL2uymhr923XvIjHAtfRJ4KJD6iDk8w5RaS0jBlTRa5wQqmCdkfUnpwU= X-Received: by 2002:a50:ef14:: with SMTP id m20-v6mr3850275eds.136.1539880902690; Thu, 18 Oct 2018 09:41:42 -0700 (PDT) MIME-Version: 1.0 References: <1538051424-24172-1-git-send-email-alejandro.lucero@netronome.com> <9c5faf3e-5a53-0ff4-9457-10165879689c@intel.com> In-Reply-To: <9c5faf3e-5a53-0ff4-9457-10165879689c@intel.com> From: Alejandro Lucero Date: Thu, 18 Oct 2018 17:41:32 +0100 Message-ID: To: "Burakov, Anatoly" , Ferruh Yigit Cc: dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] bus/pci: set intr_handle type for secondary processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 16:41:43 -0000 On Thu, Oct 18, 2018 at 5:26 PM Burakov, Anatoly wrote: > On 27-Sep-18 1:30 PM, Alejandro Lucero wrote: > > Invoking rte_pci_read/write_config functions requires device with > > a intr_handle type for using VFIO or UIO driver related functions. > > > > Secondary processes rely on primary processes for device initialization > > so they do not usually require using these functions. However, some PMD= s, > > like NFP PMD, require using these functions even for secondary processe= s. > > > > Signed-off-by: Alejandro Lucero > > --- > > Hi Alejandro, > > I=E2=80=99m curious of consequences of setting intr handle to a valid val= ue when > we don=E2=80=99t have an interrupt thread. Something may try to use it (a= lthough > I couldn=E2=80=99t find any such usage). > > The point is secondary processes do not deal with interrupts so I assume setting the type does not change anything but it allows to use PCI read/write functions by secondary processes. > PCI config read really uses intr handle type to discover userspace > driver type =E2=80=93 this seems ever so slightly wrong, and looks like > something that should be part of rte_device somewhere, independent of > interrupt types. Do we have any other alternative to do the same thing > (i.e. know what userspace driver is used for a particular PCI device)? > > I agree current way not being specially good. Your comment has reminded me there is another way: just using the kdrv field from the rte_pci_device struct. I have code using that field for doing a different thing in the NFP PMD depending on the driver in use, UIO or VFIO. So I think a better patch would be just to modify those pci functions for using kdrv field instead. Adding Ferruh in the thread for commenting on this potential change. > -- > Thanks, > Anatoly >