Add your discussion topics or comments here.
- e1000: em(4) lem(4) igb(4) -- This has been and continues to be a source of entertainment. My lab is very large.
- Request to document what e1000 devices (pci ID) are in the Bruno-lab
- gnn notes that one could just deploy the Bruno-lab to Sentex so that others can use it
- bhyve has a hardware model that uses an emulated em(4). This has not been tested. TBD
- em(4) leaking MSI-X vectors on detach
- devctl disable em0
- em0: detached
- pci0:0:25:0: Device leaked MSI vectors
- em(4) doesn't appear to be calling pci_release_msi() during detach path
ixgbe(4) -- https://reviews.freebsd.org/D11727
- Testing of conversion will resume this month. Pending.
- sbruno to send cards to Sentex lab for testing
- shurd has updated iflib to fix some of the issues defined here. Pending review.
- Can we extract Intel's test plans and deploy them to Sentex to be automated?
- There is no definition of what flags can be set and unset. No definition of behavior.
NETMAP -- https://reviews.freebsd.org/D12235
- The Hallway Track is testing. VALE doesn't appear to be fixed. NETMAP doesn't panic, but doesn't seem to pass traffic. TBD.
- It was noted that there isn't a consistent flow of code from NETMAP development into FreeBSD. TBD
Cavium Driver -- Not IFLIB -- https://reviews.freebsd.org/D11927
- Requested that we deploy a card or two to Sentex for regressions.
- Nobody seems to be maintaining this configuration. It is proposed that a user of ALTQ can use it if they simply configure their devices for single queue operation. I still don't have a test case to validate this.
- Request to audit any/all accessors of struct ifnet in IFLIB and converted drivers. Direct accesses of struct ifnet makes users of a different network stack grumpy.
- Request to standardize log messages in IFLIB with a macro for ease of automated debugging tools
- The group commented that most of this is useless nowadays and should be purged before 12.0 Release
- Request to make number of queues and descriptors per device not per driver. Users may want to configure 1 queue on em0 but use 2 queues on em1.
- dev.*.*.override_n([tr]xq|[tr]xd)s is per device, not per driver. This should work today.
- Request to make MSI-X settings per device.
- What MSI-X settings? iflib doesn't have any, but em does have a per-device MSI-X setting (dev.em.0.iflib.disable_msix)
- Request for developer and top-level docs on what all the moving parts do with regards to IFLIB.
- Request for a porting guide for developers so that there is a HOWTO on converting a device to IFLIB.
- Intel has requested assistance with regards to RDMA and IFLIB. Now that IFLIB handles device registration and configuration, IFLIB will need to grow RDMA hooks for future development of Intel network devices.
- Is it possible for IFLIB to query and configure queues and tasks in a NUMA friendly way.
- It should be only allocating tasks and queues to the socket the device is on today.
- Is there a more NUMA friendly thing we should be doing?
- Allow overrides of the NUMA configuration via loader.conf or other acceptible configurations.
- Would a cpuset tunable be enough, or is more fine-grained control desired?
- OFED update? This has requested by Intel for upcoming releases. We should have someone do this before 12 Release
