Differences

This shows you the differences between two versions of the page.

--- devsummit:201708:iflib [2017/09/07 13:25] – SeanBruno
+++ devsummit:201708:iflib [2017/09/09 13:35] (current) – SeanBruno
@@ Line 1: / Line 1: @@
-Describe [[/DevSummit|DevSummit]]/201708/IFLIB here.
+Add your discussion topics or comments here.
-- e1000
+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
+ixgbe(4) -- https://reviews.freebsd.org/D11727
+  * Testing of conversion will resume this month.  Pending.
-- routing/packet forwarding
+bnxt(4) -- First driver in the tree that uses IFLIB.
+  * sbruno to send cards to Sentex lab for testing
-- ifconfig
+routing/packet forwarding -- IFLIB derped kind of hard here.
+  * shurd has updated iflib to fix some of the issues defined here.  Pending review.
-- NETMAP
+ifconfig -- Configuration options have regressed.  This should have some kind of test suite?
+  * 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.
+ALTQ?!?!?  Really?
+  * 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.
+IFNET accessors
+  * 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.
+Standardize IFLIB log messages
+  * Request to standardize log messages in IFLIB with a macro for ease of automated debugging tools
+IFQ data and sysctls
+  * The group commented that most of this is useless nowadays and should be purged before 12.0 Release
+IFLIB per device queue and descriptor tuning
+  * 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.
+IFLIB per device MSI-X settings
+  * 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)
+IFLIB, gtaskqueue and mp_ring design docs?
+  * 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.
+IFLIB RDMA hooks
+  * 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.
+IFLIB in a NUMA world
+  * 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?
+Not IFLIB but relevant discussion
+  * OFED update?  This has requested by Intel for upcoming releases.  We should have someone do this before 12 Release
+{{devsummit/201708/iflib/iflib-postit.jpg?linkonly|IFLIB-PostIT.JPG}}