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

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

On 22/12/2017 22:33, Alex Rosenbaum wrote:
> On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal
> <mohammad.abdul.awal@intel.com> wrote:
>> On 21/12/2017 14:51, Alex Rosenbaum wrote:
>>> As described in the links Alejandro referenced earlier, each of the
>>> switch ports should be a real PMD, and switch operations should be
>>> applied on these PMD ports.
>>> This includes the steering redirection of traffic between switch ports
>>> [1], port ACL's to block/allow traffic, VST/VGT modes and anti
>>> spoofing, link trust mode [3] for promiscuous configuration, mirroring
>>> of switch port traffic, and Tx and Rx of switch port traffic to/from
>>> VF's port.
>> I agree that we need a switch_domain parameter. At the moment we do not have
>> APIs implemented for all the switch operations you have mentioned above. So,
>> we are planning separate RFC with switch _domain and related APIs.
> Sure, we can extend these switch ops in a separate step.
>
>
>>> More over, building this as real PMD ports of a switch device removes
>>> the need to add a new broker framework all together.
>>> Each vendor just needs to map additional PMD ports during the probing
>>> stage.
>> That is very much possible as well. If we agree to probe all the ports
>> during the initialization phase, we can have all the representors ready
>> without any interaction from application and broker. On the other hand, we
>> may require a broker structure to enable hotplug support.
> hotplug should be supported for any PMD ports, and any BDF type.
> I don't understand why do you need the broker framework in order to
> support hotplug?
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.

Regards,
Awal.

>
> Alex