From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 123428E01 for ; Tue, 2 Jan 2018 16:19:43 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jan 2018 07:19:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,497,1508828400"; d="scan'208";a="16227241" Received: from awalabdu-mobl.ger.corp.intel.com (HELO [163.33.228.178]) ([163.33.228.178]) by FMSMGA003.fm.intel.com with ESMTP; 02 Jan 2018 07:19:41 -0800 To: Alex Rosenbaum Cc: Declan Doherty , dev , Remy Horton , Rony Efraim , Alejandro Lucero References: <1504773339-21022-1-git-send-email-mohammad.abdul.awal@intel.com> From: Mohammad Abdul Awal Message-ID: <4b90d1b7-42c6-6c93-b360-b885ebb7415d@intel.com> Date: Tue, 2 Jan 2018 15:19:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices 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, 02 Jan 2018 15:19:44 -0000 On 27/12/2017 15:50, Alex Rosenbaum wrote: > On Wed, Dec 27, 2017 at 11:40 AM, Mohammad Abdul Awal > wrote: >> On 22/12/2017 22:33, Alex Rosenbaum wrote: >>> On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal >>>> On 21/12/2017 14:51, Alex Rosenbaum wrote: >> By hotplug I did not mean HW hotplug, rather I meant the software hotplug of >> port representor so that an application can add/delete representor at run >> time. > What is the expect results if application adds/deletes a representor > at run time? From my understanding, for OVS, it would make much sense to enumerate the representors during the startup time and only 'state' active/inactive would enough to imply the state of a VF. On the other hand, for a system with varieties of NICs/FPGAs/SmartNics having capacities of hundreds (if not thousands) of max VFs and different capabilities, we may not want to allocate them if not being using, and we may not be able to control this way if no broker. This is definitely a matter of design discussion for now where ultimate outcome is same, i.e. having a representor to control a VF. > > I would expect the VF hotplug to be depended on the PF configuration. > So that new/removed VF's would trigger a representor state or existance. I agree and as I have just said above that it is different ways of doing same thing with limited/flexible ability. > Alex Regards, Awal