Message-ID: <CAKgT0Uf2VYxOseVcenNydAXXA9acgjkePQN4tjyZzJguTWj3mA@mail.gmail.com>
Date: Sat, 6 Apr 2024 09:53:16 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: netdev@...r.kernel.org, bhelgaas@...gle.com, linux-pci@...r.kernel.org, 
	Alexander Duyck <alexanderduyck@...com>, kuba@...nel.org, davem@...emloft.net, 
	pabeni@...hat.com
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On Fri, Apr 5, 2024 at 7:01 AM Przemek Kitszel
<przemyslaw.kitszel@...el.com> 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.

Powered by blists - more mailing lists