From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B0AD0A034F; Wed, 6 May 2020 13:39:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 896651D8ED; Wed, 6 May 2020 13:39:46 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 8C2D81D8E4 for ; Wed, 6 May 2020 13:39:44 +0200 (CEST) IronPort-SDR: c4pUyONDitWDHi0nRgZYe8tUkKDwzz8sq8Krmw9bbPPjwv7/MbGAfPwIuFrhXRKOoWlAhr2eF3 HZJirDYyp24g== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2020 04:39:43 -0700 IronPort-SDR: Lso7WMKakDXx5sB1Wo5TSk8C2Vw3DByigc1lDF8uUeDEoX8WAbk3kYy7F34DyP42uKZrqYn7VC ZoQ5xOVk3Srw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,358,1583222400"; d="scan'208";a="338978319" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.209.121.37]) ([10.209.121.37]) by orsmga001.jf.intel.com with ESMTP; 06 May 2020 04:39:42 -0700 To: "Wang, Haiyue" , "dev@dpdk.org" , "thomas@monjalon.net" , "jerinj@marvell.com" , "david.marchand@redhat.com" References: <20200305043311.17065-1-vattunuru@marvell.com> <20200505103440.38455-1-haiyue.wang@intel.com> <20200505103440.38455-3-haiyue.wang@intel.com> From: "Burakov, Anatoly" Message-ID: <2b4736e6-cb0b-c2a9-aaed-6f1b80f36666@intel.com> Date: Wed, 6 May 2020 12:39:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v12 2/2] eal: support for VFIO-PCI VF token 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 06-May-20 12:35 PM, Wang, Haiyue wrote: > Hi Anatoly, > >> -----Original Message----- >> From: Burakov, Anatoly >> Sent: Wednesday, May 6, 2020 18:27 >> To: Wang, Haiyue ; dev@dpdk.org; thomas@monjalon.net; jerinj@marvell.com; >> david.marchand@redhat.com >> Subject: Re: [PATCH v12 2/2] eal: support for VFIO-PCI VF token >> >> On 05-May-20 11:34 AM, Haiyue Wang wrote: >>> The kernel module vfio-pci introduces the VF token to enable SR-IOV >>> support since 5.7. >>> >>> The VF token can be set by a vfio-pci based PF driver and must be known >>> by the vfio-pci based VF driver in order to gain access to the device. >>> >>> Signed-off-by: Haiyue Wang >>> --- >> >> >> >>> diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c >>> index 540b7d38c..00b02855e 100644 >>> --- a/lib/librte_eal/freebsd/eal.c >>> +++ b/lib/librte_eal/freebsd/eal.c >>> @@ -1002,6 +1002,11 @@ rte_eal_vfio_intr_mode(void) >>> return RTE_INTR_MODE_NONE; >>> } >>> >>> +void rte_eal_vfio_vf_token(rte_uuid_t vf_token) >>> +{ >>> + memset(vf_token, 0, sizeof(rte_uuid_t)); >>> +} >> >> What's the purpose of memset(0) here? Presumably, if the API is not >> supposed to be supported, the function should have no effect? >> > > Yes, originally I meant to no parse the input, then return zero UUID. > I changed it to the same as Linux: > rte_uuid_copy(vf_token, internal_config.vfio_vf_token); > Since it is inited to zero. Yes but on Linux it has effect because Linux supports it. On FreeBSD there's no VFIO, so the function should IMO have no effect. However, i don't have a strong opinion on this, so i'm fine either way. -- Thanks, Anatoly