Currently only admin users can create SR-IOV direct ports that are marked as switch_dev, i.e. the ones that do OVS hardware offload.
From and end user, the direct nic, hardware offloaded or not, by ovs ml2 or ovn, all appear the same. Its operator internal setup details on what happens. Why do we expose this to the end user in this way?
Example operator deployments we work with:
* all SR-IOV direct ports are offloaded using ovn
* all SR-IOV direct ports are offloaded using ovs ml2
* all SR-IOV direct ports created using legacy SR-IOV
* (not a use case I have, but theoretically its possible) some mix of the above
Ideally the user doesn't care between these, and the neutron API is able to extract away the implementation details of getting a direct type of vnic.
Currently only admin users can create SR-IOV direct ports that are marked as switch_dev, i.e. the ones that do OVS hardware offload.
From and end user, the direct nic, hardware offloaded or not, by ovs ml2 or ovn, all appear the same. Its operator internal setup details on what happens. Why do we expose this to the end user in this way?
Example operator deployments we work with:
* all SR-IOV direct ports are offloaded using ovn
* all SR-IOV direct ports are offloaded using ovs ml2
* all SR-IOV direct ports created using legacy SR-IOV
* (not a use case I have, but theoretically its possible) some mix of the above
Ideally the user doesn't care between these, and the neutron API is able to extract away the implementation details of getting a direct type of vnic.