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 AF6B0A0598; Sat, 18 Apr 2020 15:26:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A48581E883; Sat, 18 Apr 2020 15:26:56 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id 5014E1DC07 for ; Sat, 18 Apr 2020 15:26:55 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 0327D5D6; Sat, 18 Apr 2020 09:26:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 18 Apr 2020 09:26:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=YXwxilUzRl+/NBBl2Rs4p8WBWMU55HTTDCGpEISTvJM=; b=KTnK8c7yW3Rq 8vQhF4mqYXR8bRBy587vJrRlvyyvw6A1dLJhJfPfRAkcNNM0E1ucTfdEobpH8jSP VjqDQGlKtrbFgRu7/LHXocj5qwtY7AICUK5UFoISGjMnTXaUDiUMZoX3pFiSQFLE Qd9reS3DrVKu9t2ZdWOeNSHH88U/XBw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=YXwxilUzRl+/NBBl2Rs4p8WBWMU55HTTDCGpEISTv JM=; b=oEGCPpgSzpERjsPNUqJPTTenw6i8QKrjDHT8ILgMTNWUHxPBQCq+A6svx oLu7FCRm0WX1Yx1JxFn9u5Dw/LvGNRlBCOcW7/Lt8VUREG5vWxic0eCJea7TjQQs 6Qp+PCqER5v7+FndqFeeXPmcbCWoKOoBuBY22FGJgK7PeSHJUC9lPPPRQqMZvrsl lGeIb1sRAVJM5VlYDAZSkgjhPnmXD5Vpxmi+Ey6fFfuK1OJq8rsPXWNaO/X6hK7N vnV/hQtlI323VVAK5XLjwsQrp2VM2fCTarTdiNP9hCRSdLmGoWXjYI6JmIKXx1Un Qo+2uZPTRuqLXSaW24ou8ZE4m8upQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeelgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgepudenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 315E23280063; Sat, 18 Apr 2020 09:26:52 -0400 (EDT) From: Thomas Monjalon To: alex.williamson@redhat.com, david.marchand@redhat.com, Haiyue Wang Cc: dev@dpdk.org, anatoly.burakov@intel.com, vattunuru@marvell.com, jerinj@marvell.com Date: Sat, 18 Apr 2020 15:26:51 +0200 Message-ID: <12851687.OFSEd18e0E@thomas> In-Reply-To: <20200418111642.78874-3-haiyue.wang@intel.com> References: <20200305043311.17065-1-vattunuru@marvell.com> <20200418111642.78874-1-haiyue.wang@intel.com> <20200418111642.78874-3-haiyue.wang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 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" 18/04/2020 13:16, Haiyue Wang: > --- a/doc/guides/linux_gsg/linux_drivers.rst > +++ b/doc/guides/linux_gsg/linux_drivers.rst > +The Linux kernel since version 5.7 supports the creation of virtual functions, and by default this feature is off. Creation of virtual function has always been supported. You need to be more specific about the new use case please. > +After enabled, the PF needs the VF token in UUID format to setup the trust or collaboration between SR-IOV PF and VFs. > +The VFs created are bound to vfio-pci module automatically, and the VF also needs VF token to gain access to the device. > +DPDK will use the keyword ``vf_token`` as device argument to pass the VF token value to PF and its related VFs. You need to explain where the token comes from. Can it be any random UUID?