SRIOV-port creation : its possible to create more direct ports than available vif.

[Eran Kuris]

When creating sriov ports we can create more ports than vif's are avalible
for example we have 4 vifs and created more than 4 direct ports .
[root@compute1 ~(keystone_admin)]# neutron port-list
+--------------------------------------+------+-------------------+-----------------------------
| id | name | mac_address | fixed_ips |
| 22e0ae33-1f9e-47f5-9b20-2a3277b15959 | | fa:16:3e:82:52:ea | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.13"} |
| 2f6c4371-fffe-4834-a6aa-725ae72f4d02 | | fa:16:3e:9c:e9:bb | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.4"} |
| 98b62507-e21b-49e6-880e-34fa14f6b986 | | fa:16:3e:8e:73:40 | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.5"} |
| a9a28d02-4342-4575-9f9a-8ae70ab8bd2a | | fa:16:3e:7d:3f:04 | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.14"} |
| b466da32-fff4-46d8-a134-d861105e966f | | fa:16:3e:3c:81:a5 | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.6"} |
| d3601592-0133-4c65-ab85-cc142325ce29 | | fa:16:3e:c1:81:01 | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.3"} |
| d67e2fa6-6805-4baa-882e-9cf54714ba20 | | fa:16:3e:32:26:f5 | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.2"} |
| e5b5290d-1824-4bd9-aecb-81032b38ac60 | | fa:16:3e:58:8f:c9 | {"subnet_id": "212d47a3-93b7-400d-8322-84717c780e21", "ip_address": "192.168.1.7"} |
+--------------------------------------+------+-------------------+-----------------------------
[root@compute1 ~(keystone_admin)]# ip link show
4: enp5s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT qlen 1000
    link/ether a0:36:9f:7f:28:ba brd ff:ff:ff:ff:ff:ff
    vf 0 MAC fa:16:3e:3c:81:a5, vlan 208, spoof checking on, link-state auto
    vf 1 MAC fa:16:3e:9c:e9:bb, vlan 208, spoof checking on, link-state auto
    vf 2 MAC fa:16:3e:8e:73:40, vlan 208, spoof checking on, link-state auto
    vf 3 MAC fa:16:3e:c1:81:01, vlan 208, spoof checking on, link-state auto

[root@controller1 ~]# rpm -qa |grep neutron
python-neutron-7.0.4-3.el7ost.noarch
openstack-neutron-lbaas-7.0.0-2.el7ost.noarch
openstack-neutron-openvswitch-7.0.4-3.el7ost.noarch
python-neutron-fwaas-7.0.0-1.el7ost.noarch
openstack-neutron-fwaas-7.0.0-1.el7ost.noarch
python-neutron-lbaas-7.0.0-2.el7ost.noarch
openstack-neutron-ml2-7.0.4-3.el7ost.noarch
python-neutronclient-3.1.0-1.el7ost.noarch
openstack-neutron-common-7.0.4-3.el7ost.noarch
openstack-neutron-7.0.4-3.el7ost.noarch

osp 8

[QunyingRan (ran-qunying)]

I think it's not a problem, because the vf resource will be assigned during booting instance but creating a port.

[Eran Kuris (ekuris)]

Hi QunyingRan
I know that but I think its a usability bug.
As a user I think/ expect that if we have 6 Vfs that configured the system should prevent from me
to create more then 6 direct ports.
This is my opinion :)

[Brent Eagles (beagles)]

Actually I don't think we can consider this a bug. Consider:

At "birth", a neutron port is a virtual entity that, while unbound, doesn't really exist anywhere. When a guest instance is booting and is provided a port, the binding is "realized" in the real world through some actions by nova and neutron and can now be considered "consumed". Nova takes care of the book-keeping on the PCI front so we are in no danger of exceeding resources there. In order for neutron to refuse to create more VFs than exist in the system, it would have to check with nova at the time "neutron port-create" is called to know whether there will be more "direct" capable ports than VFs in the system. If the implied contract of the VF-max is pretty strict then neutron will have to poll nova quite frequently to get a known count of VFs. Any time a compute node goes down for maintenance, a PF is bound, etc. your VF-max is invalidated and reduced by some (potentially significant) number and any unbound ports may now exceed the "max". When you consider that a VF might exist on a system that has already exceeded system limits of another sort, the value of the a VFmax constraints is also somewhat suspect.

In short, I'm not sure how we could reasonably implement this and if implemented, would not be in neutron. A system management tool might be able to poll system state and reconcile the port pool, but really to what end?

[Moshe Levi (moshele)]

I agree with Brent, I think we can reject this bug