On 22/12/2017 22:33, Alex Rosenbaum wrote:
On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal
<mohammad.abdul.a...@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
