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 A0754A00BE; Fri, 1 Nov 2019 01:33:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0D84D1D417; Fri, 1 Nov 2019 01:33:55 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 177241D412 for ; Fri, 1 Nov 2019 01:33:53 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AF66F4D3; Thu, 31 Oct 2019 20:33:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 31 Oct 2019 20:33:51 -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=ioS7ST1ax0pTdjvgZ3Cvu7g2o4vDqSY1ecQdVrLJTCw=; b=Mb1pRysEwEId HmHbde5cDS5sS2Htihm3EUyfEQ6Po6Upat4vVI7UVaccEA38wKCycMG0hIeKA0yO 7DdK4LdC0HpF6HFVNWg2vL/mW2CFJUx2JqmnDw7zC2H501Tt+t8i4/bp1ojIiYmp qM7bUYffXcbW0bLokSDvLpmWeA8BBkg= 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=fm1; bh=ioS7ST1ax0pTdjvgZ3Cvu7g2o4vDqSY1ecQdVrLJT Cw=; b=CYC+UNJAO5Ubx7F4VAKJbqt73nuuMEfvPiR026fPicbwhTIm/6IDAkI/U 8nGv3+BEIpHd4itWycCBILe2q4hcWjVZrIBddBkKHyxSP2yOLggrK2fFpHTtmckw /miOY6vI4fUSTq9k6fFnJyrn5jDZlnFjc815Nbm8vtFBMd47Mka/8sNfujwuY5nA NwfIfAWaWbtyLNW88lh65SMFtM0FrKyG/TqK+DiqnMhrE7MqaTG4jfnAmNNCHpz9 1Q2zUfeAFcoeFktQ7fl20KHE12ETjqEHuANge1O+2ARxByBLbK6aF8Be5I1aNIC2 EWVD6vWmhuQjgco9ixh31M0XoGsIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtiedgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehkvghrnhgvlhdrohhrghdpughpughkrdhorhhgnecukfhppeelfedrvdef rddvhedurddvvdejnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonh hjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (227.251.23.93.rev.sfr.net [93.23.251.227]) by mail.messagingengine.com (Postfix) with ESMTPA id 72E983060060; Thu, 31 Oct 2019 20:33:48 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: dev@dpdk.org, Stephen Hemminger , Andrew Rybchenko , Ferruh Yigit Date: Fri, 01 Nov 2019 01:33:46 +0100 Message-ID: <19415242.5f0JWZHRpF@xps> In-Reply-To: References: <4165509.5enYigmRGf@xps> <4976847.S65dXbhd2F@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host 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" 30/10/2019 10:15, Jerin Jacob: > On Wed, Oct 30, 2019 at 2:26 PM Thomas Monjalon wrote: > > > > 30/10/2019 05:08, Jerin Jacob: > > > On Wed, Oct 30, 2019 at 12:21 AM Thomas Monjalon wrote: > > > > > > > > In a virtual environment, the network controller may have to configure > > > > some SR-IOV VF parameters for security reasons. > > > > > > Just to understand, Could you explain more details/examples for > > > security reasons? > > > > Examples are setting the MAC address or the promiscuous mode. > > These settings should be decided by the hypervisor, > > and not freely set by the VM. > > What is hypervisor here, rte_flow based DPDK application over using > port representor? Yes, something like that. An example is OpenStack/OVS. > > > > When the PF (host port) is driven by DPDK (OVS-DPDK case), > > > > we face two different cases: > > > > - driver is bifurcated (Mellanox case), > > > > so the VF can be configured via the kernel. > > > > - driver is on top of UIO or VFIO, so DPDK API is required, > > > > > > Not true. Both UIO and VFIO are NOT allowed to create SRIOV VF from > > > the PF device. > > > It is only allowed through igb-uio out of tree driver without iommu support. > > > > Not sure I said the contrary. > > igb_uio and vfio_pf are 2 implementations of UIO and VFIO. > > Yes. I am saying without out of tree module it is not possible. > > > > > and PMD-specific APIs were used. > > > > This new generic API will avoid vendors fragmentation. > > > > > > The API is good. But I have concerns about the vendor implementation > > > of this API. > > > It can support only vendors with bifurcated driver(Mellanox case). > > > or using igb_uio(non iommu case) but not the devices with VFIO(Which > > > is the first-class citizen). > > > > Why not? (see above) > > The API is agnostic to the kernel driver in use. > > My question is how do you enable in DPDK with VFIO if DPDK is giving > this feature? I didn't get your question. If it is the same question as before, I think you can create the VF before binding the PF to VFIO. > > > All the control plane control stuff to replace Linux with "port > > > representor" logic > > > will be of the mercy of an "out of tree" driver either with igb_uio > > > or http://patches.dpdk.org/patch/58810/ > > > > > > I am _not against_ on DPDK supports port representor or controlling > > > netdev VF traffic, > > > but if we have taken that path then DPDK should have the > > > infrastructure to support for > > > all driver models like VFIO(Addressed in [1]) > > > > > > I would have this question when DPDK starts supporting port > > > representor(but I was not > > > aware that kernel security issue on netdev ports controlled by DPDK in > > > non-bifurcated driver case > > > and concise effort block such scheme by kernel [2]) > > > > > > > > > [1] > > > http://patches.dpdk.org/patch/58810/ > > > [2] > > > https://patchwork.kernel.org/patch/10522381/ > > > > I feel you are using this thread to promote your vfio_pf implementation. > > Yes. I am. Because, I need to think, How I can enable this API with VFIO. > Otherwise, I can not implement this API. > > > But this API and the kernel module are orthogonals. > > Please can we focus on the DPDK API in this thread, > > and talk about VFIO implementation in the other thread? > > Yes. My concerns are we keep adding APIs without thinking about how it > can be implemented > in the overall scheme of things. Just API is not enough. We keep thinking about all scenarios (maybe in other threads). And adding an API is a step in the right direction in my opinion.