Support SRIOV VF VLAN Filtering

[Trevor McCasland]

a user wants to instantiate a vm on a sriov port and allow the vm to use a permitted list of vlans. The way we would do that is to use the existing trunk api to query subports to generate that list. Then take that list and provide it to VFd to configure the sriov capable NIC to do the filtering.

[Kevin Benton (kevinbenton)]

So is this proposing a new API or is this RFE just for the implementation of QinQ in the SR-IOV agent?

[Kevin Benton (kevinbenton)]

(If it is proposing a new API, please provide more details about the expected user workflow)

[Ian Wells (ijw-ubuntu)]

This sounds like it's the VLAN aware VM extension, extended to work with SRIOV (which isn't QinQ and isn't a new API either).

[Ian Wells (ijw-ubuntu)]

(Or you could do select VLANS from a flat network, conversely)

[Trevor McCasland (twm2016)]

@Ian, that sounds right.

@Keving, we want to integrate VFd at this point. It will configure the NIC to do the filtering as long as we provide it a list of VLANs for the VF.

[Kevin Benton (kevinbenton)]

Ok. let's treat this as a regular bug since it's just parity with the existing stuff.

[Ian Wells (ijw-ubuntu)]

I recommend you read the VLAN aware VM spec very carefully - first it doesn't do qinq filtering if you'd like to do that, and second I'm not quite sure whether the VLANs are user-selected or not.

(Also, I might add that 'VLAN filter' suggestion above as my own RFE...)

[Rossella Sblendido (rossella-o)]

It's possible to the get the list of subports and the segmentation ID they are using querying the API, implementing this shouldn't be a problem

[sean mooney (sean-k-mooney)]

this reads somewhat different then vlan aware vms though as this
is vlan trunking of user spcified vlans not trunking of
neutron networks using vlans as a segmentation type as supported by vlan aware vms.

so this is more akin to limited vlan transparency.

you could use this feature with vlan aware vms if the nic or tor did the neuron segment id
to subport segment id mapping.

complementary to that if the port was connect to a vlan transparent flat network this
capablity would allow you to limit the vlans that are received or set by the sriov port.

This was discussed at the ptg in the context of trippleO where a flatnetwork woudl be
used to establish the underlay network in neutron with this limited vlan trunk used to isolate the over cloud deployment onto without the need to create 1000s subports per port to chacive the same with effect with vlan aware vms.

[sean mooney (sean-k-mooney)]

by the way that comment is based on the orginal descripton no the update one that mentions subports but im not conviced subport are nessicarlly the best approch but
it the intent is just make vlan aware vms work with sriov i think that is also a good thing
though i i recall correctly trevor you request at the ptg went beyond that?

[Ian Wells (ijw-ubuntu)]

That would be my point about 'vlan filtering' - which I think is a lot closer to what we actually want to use. VLAN aware VMs was intended to allow more network connections than you can reasonably have ports. If you're doing NFV you're often looking at a limited trunk, which it *can* do but which it's not good at.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/476547

[Ihar Hrachyshka (ihar-hrachyshka)]

I am still puzzled about the comments and the current description. My reading is the ask here is to support vlan_transparent API extension for SR-IOV ports, so that instances get all the incoming traffic when VIF is in promiscuous mode. Is it the case? If so, it seems like the description would need some love.

But if it's asking to support trunk ports for SR-IOV, then it's a different thing. Again, then we need to update description to reflect that.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/476547

[Munish (mm6021)]

We have agreement from Nic vendors now to do this in kernel drivers via sysfs. In the nic driver, the trunk sysfs kobject supports two operations: add and rem. The add operator supports users to add one or more VLAN id into VF VLAN filtering. The rem operator supports removing VLAN ids from the VF VLAN filtering list.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.