From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id E06971B1E3 for ; Wed, 10 Jan 2018 20:26:31 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D455E20B4F; Wed, 10 Jan 2018 14:26:30 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 10 Jan 2018 14:26:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=K4dgc2NWyXCve8umWEirrXcaic QNAJM/7q15fFU4OYg=; b=szydslXv8ZtNUF6m4qYk6otLTy+zRwGGAnjDJkw4Qi 7o+oguBRq67kE2V4w3InL0mFD7byXz6spSjTIT4OqpO3ZWMN2S5tBffspjfxY48n cQX0lSXkdReESe2MirkOQI+PrS1skoCkyvdTFhQDu6nb8f3kB6nSXNj90YJ9B0VJ U= 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=K4dgc2 NWyXCve8umWEirrXcaicQNAJM/7q15fFU4OYg=; b=AvMlJh67w5q8pup+Ct7+Qy 2UmDTVomL8V71WfmYgbXeXq30Ar0fiow0GpYdQ8zq7TRY4Ras2orGGDjAco44ldV UOyzDsx1hmDrdH6nJIJqiYGJMAglaRdh7C+riAzWEAn015/i0Y79JhjT3r4Etux2 iw9bFpFvv6WC2G0sApiVJgqfVPMlf0YR0ipP9Lc6zztzcejdxHMmxbRcIyumdqk2 KueDovXvSEk9htxDF0Xl+ODbTUK5UyTyfVW+6geJCZc5geSRU3SBopX/G/tjKosb 9bXztiO9FztsZgGFYJ7zd44OqXk+6NPM+wjSh/13G2yetqBmim81/C3/KwyJSp4w == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 68B857E34B; Wed, 10 Jan 2018 14:26:30 -0500 (EST) From: Thomas Monjalon To: "Doherty, Declan" Cc: Remy Horton , Mohammad Abdul Awal , dev@dpdk.org, John McNamara , Wenzhuo Lu , Jingjing Wu , Alejandro Lucero , vincent.jardin@6wind.com Date: Wed, 10 Jan 2018 20:26:04 +0100 Message-ID: <2447572.KKM6cvjoYG@xps> In-Reply-To: References: <20180108143720.7994-1-remy.horton@intel.com> <2463277.U5nOFtZCo4@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 0/5] lib: add Port Representors 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: Wed, 10 Jan 2018 19:26:32 -0000 10/01/2018 14:46, Doherty, Declan: > On 09/01/2018 11:22 PM, Thomas Monjalon wrote: > > Hi, > > > > 08/01/2018 15:37, Remy Horton: > >> Port Representors provide a logical presentation in DPDK of VF (virtual > >> function) ports for the purposes of control and monitoring. Each port > >> representor device represents a single VF and is associated with it's > >> parent physical function (PF) PMD which provides the back-end hooks for > >> the representor device ops and defines the control domain to which that > >> port belongs. This allows to use existing DPDK APIs to monitor and control > >> the port without the need to create and maintain VF specific APIs. > > > > Extending control plane ability of DPDK has been discussed > > multiple times. > > It has, and I have yet to see a really strong reason as to why we would > not support control plane functions within DPDK, many of which are > already support today implicitly anyway through our ethdev APIs. > > > The current agreed policy is: > > " > > The primary goal of DPDK is to provide a userspace dataplane. > > Managing VFs from a PF driver is a control plane feature and developers > > should generally rely on the Linux Kernel for that. > > " > > http://dpdk.org/doc/guides/contributing/design.html#pf-and-vf-considerations > > > > My understanding is that this particular entry was based around the > discussion on the divergence of functionality between the Linux kernel > PF driver and the DPDK PF driver. I also don't really think the above > statement is valid as a blanket statement for the project as it makes > the assumption that DPDK is only deployed on Linux hosts, what about > FreeBSD? or in the future Windows? Yes, we must agree on removing this scope limitation while working on a generic VF representor. > A number of presentations at both Userspace in Dublin and the Summit > in San Jose discussed the support of control plane functionality by > DPDK and there wasn't any strong arguments or opposition against using > DPDK for control plane functions that I saw. > > In any case this patchset is not introducing any new control plane APIs > that don't already exist within DPDK today, it only enables the creation > of a new type of virtual PMDs which are linked to the same base > infrastructure and which can be used to represent VFs in a control plane > application as we have implemented in this patch set. > > > If we relax this policy, I think the representor solution should be > > a real port, not only "for the purposes of control and monitoring". > > It has been asked several times as replies to this series, > > but it is kindly ignored, saying it will be thought later. > > > > I think we have stated in multiple discussions, especially during the > userspace presentation back in September that this solution supports > data path on the representors PMDs, and we have used the > infrastructure proposed here to do exactly what you are asking. As the > representor infrastructure doesn't preclude the support of a data > path, we have used it as it is presented here to implement a data path > for exception path packets for a prototype vswitch offload implementation. > > > > I don't see a general agreement on this series so far. > > > > I think the main issue of contention is that there is a > misunderstanding that this implementation only supports control plane > management and monitoring, but that is not the case and it can be used > for full data path representors, with limited or no control plane > functionality if required, at the end of the day the only limitations > are based on what is implemented by the backend base driver were the > broker is running for the representor ports. The misunderstanding may originates from what you describe (even in v5): "ports for the purposes of control and monitoring" I think everybody agree to have VF representors in DPDK. But there are few things which are not generic enough, and not easy to use. I hoped the discussion started at Dublin would continue on the mailing list but I realize the joint effort with other vendors did not happen. I will elaborate quickly below and more detailed in later review. 1/ In order to keep track of the relations between PF, VF and representor - which are all ethdev - you create a struct outside of ethdev. I think it should be managed inside ethdev API. As suggested by others, we could also think whether a switchdev API is interesting or not. 2/ You create a new library for ethdev device management. It is the responsibility of the bus to scan and probe devices. In Intel case, the representor has no real bus so it must rely on the vdev bus. Note that the new custom scan hook may help. In Mellanox case, the representor already exists in Linux, and is based on PCI bus. Then, as any other port, it must be managed with whitelist or blacklist. 2-bis/ Minor comments about this lib: - it is not convenient to ask user or app to enable it - it is not using dynamic logging 3/ You are using PCI address + index to identify the representor. It is a no-go. We have made effort to abstract buses. As an idea, the identification of a representor could use the new proposed flexible device syntax. 4/ Such new API must be experimental. I propose to better think the representor API inside ethdev with a good multi-vendor collaboration, and submit a deprecation notice for 18.05 integration.