From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id 27F6F234 for ; Fri, 27 Mar 2015 07:01:53 +0100 (CET) Received: by pacwz10 with SMTP id wz10so34812938pac.2 for ; Thu, 26 Mar 2015 23:01:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BO56nAiFeoOUUo2wA4Y/aUDmcZqZzAupAxqT/TGm/Uk=; b=PD715iBWVkzYS2RfeopU2vt1Z/Ul3JUJBHSD9bmSN8YyYNwsBbFeCThgLgnVUl21gn +khFhxSAb3Rs/kQk1TIz4MtSmXv9ZX40Xen9q/9q1f4z4Vc6kDTI9NiOQGieaghl3dpg W+9u96iIfKnvZhtk+cP7/i4s9xNfck1zt5AGLpiYPT9Zilp02Du7+TnHYuV6RZqmSUz1 CzQb4blwt8BmmWDRx3DC8S7am5Xdou1NB51Etk+dzFKv/W0Uk5FalEzXfvPp+gFat51s pvBSio6fwCu5cIiVwYjvpkhg8b0mAAAH4DG0+ixVocMknmfWpubeKvEfJyj4G1J17SiW a5dA== X-Gm-Message-State: ALoCoQkde4GOuUzD7D5d0Tu4nflvEhrBozcoI5es8n+MSotHd6h8N52Zv1qSf8lACw4u+jHOY8yL X-Received: by 10.68.220.227 with SMTP id pz3mr32624968pbc.72.1427436112212; Thu, 26 Mar 2015 23:01:52 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id nj5sm896507pdb.35.2015.03.26.23.01.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 23:01:51 -0700 (PDT) Message-ID: <5514F24B.8030107@igel.co.jp> Date: Fri, 27 Mar 2015 15:01:47 +0900 From: Tetsuya Mukawa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Iremonger, Bernard" , Stephen Hemminger References: <1426584645-28828-7-git-send-email-mukawa@igel.co.jp> <1427170717-13879-1-git-send-email-mukawa@igel.co.jp> <1427170717-13879-3-git-send-email-mukawa@igel.co.jp> <20150324113321.789c96a1@urahara> <551228CC.3000507@igel.co.jp> <20150324220752.45b4ca0e@urahara> <551388B4.5000905@igel.co.jp> <8CEF83825BEC744B83065625E567D7C204A02764@IRSMSX108.ger.corp.intel.com> In-Reply-To: <8CEF83825BEC744B83065625E567D7C204A02764@IRSMSX108.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 2/6] eal: Close file descriptor of uio configuration X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 06:01:53 -0000 On 2015/03/26 19:03, Iremonger, Bernard wrote: > >> -----Original Message----- >> From: Tetsuya Mukawa [mailto:mukawa@igel.co.jp] >> Sent: Thursday, March 26, 2015 4:19 AM >> To: Stephen Hemminger >> Cc: Iremonger, Bernard; david.marchand@6wind.com; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v2 2/6] eal: Close file descriptor of uio configuration >> >> On 2015/03/25 14:07, Stephen Hemminger wrote: >>> On Wed, 25 Mar 2015 12:17:32 +0900 >>> Tetsuya Mukawa wrote: >>> >>>> On 2015/03/25 3:33, Stephen Hemminger wrote: >>>>> On Tue, 24 Mar 2015 13:18:33 +0900 >>>>> Tetsuya Mukawa wrote: >>>>> >>>>>> When pci_uio_unmap_resource() is called, a file descriptor that is >>>>>> used for uio configuration should be closed. >>>>>> >>>>>> Signed-off-by: Tetsuya Mukawa >>>>>> --- >>>>>> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 6 +++++- >>>>>> 1 file changed, 5 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c >>>>>> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c >>>>>> index 9cdf24f..f0277be 100644 >>>>>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c >>>>>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c >>>>>> @@ -459,8 +459,12 @@ pci_uio_unmap_resource(struct rte_pci_device >>>>>> *dev) >>>>>> >>>>>> /* close fd if in primary process */ >>>>>> close(dev->intr_handle.fd); >>>>>> - >>>>>> dev->intr_handle.fd = -1; >>>>>> + >>>>>> + /* close cfg_fd if in primary process */ >>>>>> + close(dev->intr_handle.uio_cfg_fd); >>>>>> + dev->intr_handle.uio_cfg_fd = -1; >>>>>> + >>>>>> dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; } #endif /* >>>>>> RTE_LIBRTE_EAL_HOTPLUG */ >>>>> For the Qlogic/Broadcom driver it needed the config fd handle, and I >>>>> added generic config space access functions. >>>> Hi Stephen, >>>> >>>> Is this the patch you mentioned? >>>> http://dpdk.org/dev/patchwork/patch/3024/ >>>> >>>> >>>> Hi David, Bernard, Stephen >>>> >>>> I guess here are works we will need to do. >>>> 1. Add close(dev->config_fd) in Stephen's patch. >>>> 2. Write a patch for uio to merge "dev->intr_handle->uio_cfg_fd" and >>>> "dev->config_fd". >>>> 3. Write a patch for vfio to merge "dev->intr_handle->vfio_cfg_fd" >>>> and "dev->config_fd". >>>> >>>> If we already have these patches, I guess it may be nice to merge >>>> above patches first. >>>> Do you have a suggestion how to merge patches related with pci config fd? >>>> >>>> Thanks, >>>> Tetsuya >>>> >>> Yeah, that is the patch. It reopens config fd, it seems to overlap >>> this. >> Hi Stephen, David, Bernard, >> >> If you are OK, I will cherry pick below Stephen's patch, then put it on top of my patches. >> - http://dpdk.org/dev/patchwork/patch/3024/ >> >> Also I will write patches to merge following fds. >> - dev->config_fd >> - dev->intr_handle->uio_cfg_fd >> - dev->intr_handle->vfio_cfg_fd >> >> Is this direction OK? >> >> >> Stephen, >> >> For uio, I guess it will be OK that I just replace pread/pwrite by your APIs. >> But for vfio, I need to write a function to wrap vfio ioctl. >> May be rte_eal_pci_ioctl_config()? >> And replace all vfio ioctls by the function. >> Is this correct way to adopt your APIs for vfio? >> >> Regards, >> Tetsuya > Hi Tetsuya, > > It would be better not to broaden the scope of the BSD cleanup patch set at this point. > It would be better to have a separate patch set to apply Stephen's changes to the BSD code base. > Also, discussion is still ongoing on Stephen's changes so it might be better to wait until the discussion is completed. Hi Bernard, Thanks for comments. I will focus on BSD thing. Regards, Tetsuya > Regards, > > Bernard. > > >