Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices

[Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>]

On 27/12/2017 15:50, Alex Rosenbaum wrote:
> On Wed, Dec 27, 2017 at 11:40 AM, Mohammad Abdul Awal
> <mohammad.abdul.awal@intel.com> 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