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
Details
Details
- Reviewers
jhb kib np - Group Reviewers
network - Commits
- rGc57c26179033: iovctl: allow vlan restrictions to be passed to the driver
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
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.
Comment Actions
I only ask you to push the mlx5 changes as a standalone commit (it makes things easier for us internally).
Comment Actions
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. | |
| 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. | |
| 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? | |
| usr.sbin/iovctl/iovctl.conf.5 | ||
|---|---|---|
| 99 | BTW VID 0 encapsulation is useful. | |
Comment Actions
- 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'.