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

[Alex Rosenbaum <rosenbaumalex@gmail.com>]

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?

Alex