On Fri, Apr 5, 2024 at 7:01 AM Przemek Kitszel <przemyslaw.kitszel@xxxxxxxxx> wrote: > > On 4/3/24 22:08, Alexander Duyck wrote: > > This patch set includes the necessary patches to enable basic Tx and Rx > > over the Meta Platforms Host Network Interface. To do this we introduce a > > new driver and driver and directories in the form of > > "drivers/net/ethernet/meta/fbnic". > > > > Due to submission limits the general plan to submit a minimal driver for > > now almost equivalent to a UEFI driver in functionality, and then follow up > > over the coming weeks enabling additional offloads and more features for > > the device. > > > > The general plan is to look at adding support for ethtool, statistics, and > > start work on offloads in the next set of patches. > > > > --- > > > > Alexander Duyck (15): > > PCI: Add Meta Platforms vendor ID > > eth: fbnic: add scaffolding for Meta's NIC driver > > eth: fbnic: Allocate core device specific structures and devlink interface > > eth: fbnic: Add register init to set PCIe/Ethernet device config > > eth: fbnic: add message parsing for FW messages > > eth: fbnic: add FW communication mechanism > > eth: fbnic: allocate a netdevice and napi vectors with queues > > eth: fbnic: implement Tx queue alloc/start/stop/free > > eth: fbnic: implement Rx queue alloc/start/stop/free > > eth: fbnic: Add initial messaging to notify FW of our presence > > eth: fbnic: Enable Ethernet link setup > > eth: fbnic: add basic Tx handling > > eth: fbnic: add basic Rx handling > > eth: fbnic: add L2 address programming > > eth: fbnic: write the TCAM tables used for RSS control and Rx to host > > > > > > MAINTAINERS | 7 + > > drivers/net/ethernet/Kconfig | 1 + > > drivers/net/ethernet/Makefile | 1 + > > drivers/net/ethernet/meta/Kconfig | 29 + > > drivers/net/ethernet/meta/Makefile | 6 + > > drivers/net/ethernet/meta/fbnic/Makefile | 18 + > > drivers/net/ethernet/meta/fbnic/fbnic.h | 148 ++ > > drivers/net/ethernet/meta/fbnic/fbnic_csr.h | 912 ++++++++ > > .../net/ethernet/meta/fbnic/fbnic_devlink.c | 86 + > > .../net/ethernet/meta/fbnic/fbnic_drvinfo.h | 5 + > > drivers/net/ethernet/meta/fbnic/fbnic_fw.c | 823 ++++++++ > > drivers/net/ethernet/meta/fbnic/fbnic_fw.h | 133 ++ > > drivers/net/ethernet/meta/fbnic/fbnic_irq.c | 251 +++ > > drivers/net/ethernet/meta/fbnic/fbnic_mac.c | 1025 +++++++++ > > drivers/net/ethernet/meta/fbnic/fbnic_mac.h | 83 + > > .../net/ethernet/meta/fbnic/fbnic_netdev.c | 470 +++++ > > .../net/ethernet/meta/fbnic/fbnic_netdev.h | 59 + > > drivers/net/ethernet/meta/fbnic/fbnic_pci.c | 633 ++++++ > > drivers/net/ethernet/meta/fbnic/fbnic_rpc.c | 709 +++++++ > > drivers/net/ethernet/meta/fbnic/fbnic_rpc.h | 189 ++ > > drivers/net/ethernet/meta/fbnic/fbnic_tlv.c | 529 +++++ > > drivers/net/ethernet/meta/fbnic/fbnic_tlv.h | 175 ++ > > drivers/net/ethernet/meta/fbnic/fbnic_txrx.c | 1873 +++++++++++++++++ > > drivers/net/ethernet/meta/fbnic/fbnic_txrx.h | 125 ++ > > include/linux/pci_ids.h | 2 + > > 25 files changed, 8292 insertions(+) > > Even if this is just a basic scaffolding for what will come, it's hard > to believe that no patch was co-developed, or should be marked as > authored-by some other developer. > > [...] I don't want to come across as snarky, but you must be new to Intel? If nothing else you might ask a few people there about the history of the fm10k drivers. I think I did most of the Linux and FreeBSD fm10k drivers in about 2 to 3 years. Typically getting basic Tx and Rx up and running on a driver only takes a few weeks, and it is pretty straight forward when you are implementing the QEMU at the same time to test it on. From my experience driver development really goes by the pareto principle where getting basic Tx/Rx up and running is usually a quick task. What takes forever is enabling all the other offloads and functions. As far as this driver goes I would say this is something similar, only this time I have worked on a Linux and UEFI driver, both of which I am hoping to get upstreamed. With that said I can go through the bits for the yet to be upstreamed parts that weren't done by me. We had tried to bring a few people onto the team early on, none of which are with the team anymore but a couple are still with the company so I can reach out to them and see if they are okay with the Co-autthor attribution before I submit those patches. I have a few people who worked on the ptp and debugfs, one that enabled Tx offloads and the ethtool ring configuration, and another had just started work on the UEFI driver before he left. In addition there was an Intern who did most of the work on the ethtool loopback test. When the layoffs hit in late 2022 the team was basically reduced to just myself and a firmware developer. Neither of us really strayed too much into the other's code. Basically I defined the mailbox interface and messages and went on our separate ways from there. In the last 6 months our team started hiring again. The new hires are currently working in areas that aren't in this set such as devlink firmware update, ethtool register dump, and various other interactions with the firmware.
