From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 2F8A25F65 for ; Fri, 19 Oct 2018 10:02:46 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 01:02:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,399,1534834800"; d="scan'208";a="79965785" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.17.135]) ([10.252.17.135]) by fmsmga008.fm.intel.com with ESMTP; 19 Oct 2018 01:02:45 -0700 To: Alejandro Lucero , Ferruh Yigit Cc: dev References: <1538051424-24172-1-git-send-email-alejandro.lucero@netronome.com> <9c5faf3e-5a53-0ff4-9457-10165879689c@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 19 Oct 2018 09:02:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Fri, 19 Oct 2018 08:02:47 -0000 On 18-Oct-18 5:41 PM, Alejandro Lucero wrote: > > > 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 PMDs, > > like NFP PMD, require using these functions even for secondary > processes. > > > > Signed-off-by: Alejandro Lucero > > > --- > > Hi Alejandro, > > I’m curious of consequences of setting intr handle to a valid value > when > we don’t have an interrupt thread. Something may try to use it > (although > I couldn’t 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 – 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. > I definitely think the way you describe would be a better way to fix this (i.e. use kdrv in PCI config functions rather than intr handle type). -- Thanks, Anatoly