From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by dpdk.org (Postfix) with ESMTP id F416B1B202 for ; Fri, 19 Oct 2018 16:57:41 +0200 (CEST) Received: by mail-ed1-f68.google.com with SMTP id y19-v6so31712228edd.2 for ; Fri, 19 Oct 2018 07:57:41 -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=ETxJ5b7klEBWcKgPSWuke/lIqU0itRU5OGj9QyTHSfg=; b=L1xkxrxwXAsAoMwRc7aBNJK5KUGhk5U6IzVNK77C5gTTeI3xkfNTqcysuaVq4FUgoY lLXo8gCPRoU5pOtNk88/ol51aHsvv1+m8m6peNKg3QcG5kn2SvNavF6CJ3R8jniMBRHc 5IAIGAhxTZ8YthNWTdE5iSxIIvlKzZEox8ULUcAHHY9K09PK8xAxLJwVS+bDRkaxSbOf +IcfPYuaEO1prVGKzxjKZVtt5PKFJPm7vh6VpwSkmB5DY0vkx02SH5C4Bqrdvo7JAo58 9KNCZeQF8iDU4XzVHGSmWD3x9EpkCbD0h0heJswkbBkMzXZy9VZv2035hKL1sFL5ND4s DmXQ== 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=ETxJ5b7klEBWcKgPSWuke/lIqU0itRU5OGj9QyTHSfg=; b=YROWiCoL07laBCy3Zf1pB4kY/KfprGMf6fbMmcOajk78T7PyLCojIsLvuMT6q0HkRu 9eRIph/WAK6W5ex1MkIxRpIxUB5fzpsieGd2hmt0JxwROpc/1Qw/SAWeMGCMlNDP0quy jZrgoCVttSFE0A9vdZ0/tV6b6PD86g24MbabTvR9Hgx4Qiwj3srjffsfnY1WwxSfZxMh FZwyRCAHxhx/h8dnwSkomW/plwbM0bcGV2ct1p3g6QZykOhdjD6iuBrr9gtX8oNe4UIT joUxdtY8gDKKSGJz89Oa/Q2utKw9GlutiS24Az+FfvaNTHivTsiPpNE69tH6MjvXQJxR eY0w== X-Gm-Message-State: ABuFfogKleBCsiDfW+3YWVa9nHdluy03zl5ZpeCT6b9MuSc16NsK00rL tVeYQCGrjoiwoTDnMwCGGgnpgpqCSnagQwja4To71g== X-Google-Smtp-Source: ACcGV63PHCl6fhadZTtdMQBwj1tmhH4Xa9uUYeZvnJ5omG1l2XB8cT7SKcx3FpSv1vWFZyI/5JE0blRRg3w+JkgAvO0= X-Received: by 2002:a50:9386:: with SMTP id o6-v6mr6785758eda.248.1539961061426; Fri, 19 Oct 2018 07:57:41 -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: From: Alejandro Lucero Date: Fri, 19 Oct 2018 15:57:30 +0100 Message-ID: To: "Burakov, Anatoly" Cc: Ferruh Yigit , 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: Fri, 19 Oct 2018 14:57:42 -0000 On Fri, Oct 19, 2018 at 9:02 AM Burakov, Anatoly wrote: > 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 wit= h > > > a intr_handle type for using VFIO or UIO driver related function= s. > > > > > > 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=E2=80=99m curious of consequences of setting intr handle to a val= id value > > when > > we don=E2=80=99t have an interrupt thread. Something may try to use= it > > (although > > I couldn=E2=80=99t find any such usage). > > > > > > The point is secondary processes do not deal with interrupts so I assum= e > > 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 pc= i > > 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)= . > > I will send another patch then. Thanks! > -- > Thanks, > Anatoly >