Session

Current Agenda

1) How to improve the process of new device driver upstreaming, setting reasonable expectation for the submitter, the reviewers and maintainers, and eventual (process) documentation gaps to try to reduce the very high number of iterations (some) newcomers are stuck with

• Paolo Abeni

2)ixd and idpf are 2 intel ethernet drivers that are targeted for multiple generations of intel ethernet products in various formats like discrete PCI NIC across multiple hosts, SOC NIC, SOC SWITCH and IPU, all based on a common networking IP. idpf is a open specification based unified pf/vf ethernet driver supporting IDPF pci programming interface. It has been in the upstream linux kernel for past few years, supported in linux kernel distributions across x86/ARM architectures and widely deployed in google cloud environments. ixd is a new control+data path driver that supports switchdev framework to provision, configure, control and manage devices that expose idpf data path functions. In this talk we will go over the driver architecture, design, challenges and the strategy we are following to refactor idpf to enable sharing the code between the 2 drivers. We will also go over the various PCI functions(PF/VF), Subfunctions exposed by the device and the drivers loaded to support the possible configurations and device modes.

• Sridhar Samudrala And Jayaprakash Shanmugam

3) The auxiliary bus gives us a clean way to split a single PCI device into multiple cooperating drivers, but its communication model is limited: the parent (aux_device creator) exposes data to the child (aux_driver), and the child consumes them. There is no first-class mechanism for either side to notify the other of events (asynchronous or synchronous) like link change, reset, FLR, capability change, config update, teardown intent, or specific kernel API calls targeted at the child but requiring parent resources to complete.

• David Ertman