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 F37373257 for ; Wed, 10 Jan 2018 00:22:32 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7621B20921; Tue, 9 Jan 2018 18:22:32 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 09 Jan 2018 18:22:32 -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=mAB6xc95yw7+2/lMJeS7Q6ZkNt StyWgiCUPwIi/f8Q4=; b=lrC5gdSy8zh7Pb+jQHPjd4oN7QE84dMMYV1SxbSQkl /KvjeRS5nkTGZoS+KdrU2DANJXUjnX2Gc/zgoZ3ZTUV84qy0+eea9pRAUvehHoHq iLmk8wv4PhFw5mByX6k8Zarwx9xFH1Tk7QLhG0Us/KjNtU8qm1UgPegcHFKlxe9r s= 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=mAB6xc 95yw7+2/lMJeS7Q6ZkNtStyWgiCUPwIi/f8Q4=; b=TYfg9tGTHtgHfeBQuQDDSX cXgVDoGgpZ8C6fsgeyb6s38AVXYJLYGj5/pNct6SJbbj2g4DSF5l+YQ72j015vtC KV/3JKR9PEofqJpIJkeE2aW1EihFwbgUnI2/ht5BH4HI4Oi1bV2lrqh9K8MA7Vvw /G4gS5ABn1APCAos+awJWMJ+NbwWgZZ40oQi8mUgw6UCBTtvd7j+gdN1tdIGUvOa kOoVY4CfhuUNlJckEeYRHkuSb/Xvc/lTahYymhKFQmWVW+LcewaSsN26fOqpRBZ+ G6Ogq47rWAyp4H1DdIUReyc7jX51jmOAC1929tE8Td57VSgUtj2Z2iTvv05rX44g == 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 1ABB07E3DE; Tue, 9 Jan 2018 18:22:32 -0500 (EST) From: Thomas Monjalon To: Remy Horton , Mohammad Abdul Awal , Declan Doherty Cc: dev@dpdk.org, John McNamara , Wenzhuo Lu , Jingjing Wu , Alejandro Lucero , vincent.jardin@6wind.com Date: Wed, 10 Jan 2018 00:22:07 +0100 Message-ID: <2463277.U5nOFtZCo4@xps> In-Reply-To: <20180108143720.7994-1-remy.horton@intel.com> References: <20180108143720.7994-1-remy.horton@intel.com> 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: Tue, 09 Jan 2018 23:22:33 -0000 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. 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 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 don't see a general agreement on this series so far.