Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

Alexander Duyck
2024-04-06T17:16:47Z

On Sat, Apr 6, 2024 at 9:49 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > I'm assuming it is some sort of firmware functionality that is needed
> > to enable it? One thing with our design is that the firmware actually
> > has minimal functionality. Basically it is the liaison between the
> > BMC, Host, and the MAC. Otherwise it has no role to play in the
> > control path so when the driver is loaded it is running the show.
>
> Which i personally feel is great. In an odd way, this to me indicates
> this is a commodity product, or at least, leading the way towards
> commodity 100G products. Looking at the embedded SoC NIC market, which
> pretty is much about commodity, few 1G Ethernet NICs have firmware.
> Most 10G NICs also have no firmware. Linux is driving the hardware.
>
> Much of the current Linux infrastructure is limited to 10G, because
> currently everything faster than that hides away in firmware, Linux
> does not get to driver it. This driver could help push Linux
> controlling the hardware forward, to be benefit of us all. It would be
> great if this driver used phylink to manage the PCS and the SFP cage,
> that the PCS code is moved into drivers/net/pcs, etc. Assuming this
> PCS follows the standards, it would be great to add helpers like we
> have for clause 37, clause 73, to help support other future PCS
> drivers which will appear. 100G in SoCs is probably not going to
> appear too soon, but single channel 25G is probably the next step
> after 10G. And what is added for this device will probably also work
> for 25G. 40G via 4 channels is probably not too far away either.
>
> Our Linux SFP driver is also currently limited to 10G. It would be
> great if this driver could push that forwards to support faster SFP
> cages and devices, support splitting and merging, etc.
>
> None of this requires new kAPIs, they all already exist. There is
> nothing controversial here. Everything follows standards. So if Meta
> were to abandon the MAC driver, it would not matter, its not dead
> infrastructure code, future drivers would make use of it, as this
> technology becomes more and more commodity.
>
> Andrew

As far as the MAC/PCS code goes I will have to see what I can do. I
think I have to check with our sourcing team to figure out what
contracts are in place for whatever IP we are currently using before I
can share any additional info beyond the code here.

One other complication I can think of in terms of switching things
over as you have requested is that we will probably need to look at
splitting up the fbnic_mac.c file as it is currently used for both the
UEFI driver and the Linux driver so I will need to have a solution for
the UEFI driver which wouldn't have the advantage of phylink.

Thanks,

- Alex