iovctl: allow vlan restrictions to be passed to the driver

[kp]

Summary

Allow iovctl to create VFs that are restricted to specific VLAN IDs.
This is supported by the cxgbe and mlx5 drivers.

MFC after: 2 weeks
Sponsored by: Orange Business Services

[kp]

I've not been able to test the mxl5 changes as I don't have access to the hardware.

And the cxgbe patch doesn't quite work, because the VM VF generates errors like kernel: t6vf0: FW_ERROR (non-fatal) ACL cidx 1 PF 0 VF 1 eqid 18449 MAC 80 00 00 00 01 00. I'm not entirely clear on what I'm doing wrong, but I figured I'd post it so people more familiar with the relevant drivers can offer feedback.

[kib]

I only ask you to push the mlx5 changes as a standalone commit (it makes things easier for us internally).

[zlei]

Allow iovctl to create VFs that are restricted to specific VLAN IDs.

So will the restricted VFs work much like vlan(4) devices over PF ? Or vlan(4) over VF is still needed to pass in tagged packets to the net stack?

sys/dev/pci/pci_iov_schema.c

362

VID 0xFFF (4095) is reserved for implementation use. What is the expected behavior when user request to restrict that VID ?

usr.sbin/iovctl/iovctl.conf.5

99

no VLAN tag aka untagged ?

164

Can VFs be restricted to multiple VLANs ? So by default they are not restricted, aka permit all VLANs.

[kp]

sys/dev/pci/pci_iov_schema.c

362

I'd assume it'll end up with a VID of 4095.

I mirrored the check from if_vlan.c's vlan_clone_create_nl(). Looking at that a bit more closely, it looks like vlan_config() has a subtly different check, and would not accept VID 4095. We probably want to align those two checks in if_vlan.c though.

I think it's best for the framework here to allow vid 4095, in case the specific driver can do something useful in that case. The driver still has an opportunity to reject the value if it can't do anything sane with it.

usr.sbin/iovctl/iovctl.conf.5

99

Yes.

164

The two drivers I've looked at do not appear to support that. It's also how the Linux API works: one VLAN per VF.
So I'd keep things simple here, we can always make them more complicated later if that turns out to be needed.

[markj]

usr.sbin/iovctl/iovctl.conf.5

99

It's possible to use VID 0 in general though. I'm not sure whether it really makes sense to assign VID 0 to a VF, but are we painting ourselves into a corner by using 0 as a nil value here?

[kib]

usr.sbin/iovctl/iovctl.conf.5

99

BTW VID 0 encapsulation is useful.

[kp]

• Move driver changes into separate commits
• support 'vlan: trunk;', indicating there's no vlan filtering For this we pass vlan id 4096, which drivers translate into meaning 'no vlan acl'. This allows drivers that can handle it to use vlan id 0 to mean 'vlan header, but logically untagged'.