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

Alexander Duyck
2024-04-04T14:45:52Z

On Thu, Apr 4, 2024 at 4:37 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Wed, Apr 03, 2024 at 10:08:24PM CEST, alexander.duyck@gmail.com 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.
>
> Could you please shed some light for the motivation to introduce this
> driver in the community kernel? Is this device something people can
> obtain in a shop, or is it rather something to be seen in Meta
> datacenter only? If the second is the case, why exactly would we need
> this driver?

For now this is Meta only. However there are several reasons for
wanting to include this in the upstream kernel.

First is the fact that from a maintenance standpoint it is easier to
avoid drifting from the upstream APIs and such if we are in the kernel
it makes things much easier to maintain as we can just pull in patches
without having to add onto that work by having to craft backports
around code that isn't already in upstream.

Second is the fact that as we introduce new features with our driver
it is much easier to show a proof of concept with the driver being in
the kernel than not. It makes it much harder to work with the
community on offloads and such if we don't have a good vehicle to use
for that. What this driver will provide is an opportunity to push
changes that would be beneficial to us, and likely the rest of the
community without being constrained by what vendors decide they want
to enable or not. The general idea is that if we can show benefit with
our NIC then other vendors would be more likely to follow in our path.

Lastly, there is a good chance that we may end up opening up more than
just the driver code for this project assuming we can get past these
initial hurdles. I don't know if you have noticed but Meta is pretty
involved in the Open Compute Project. So if we want to work with third
parties on things like firmware and hardware it makes it much easier
to do so if the driver is already open and publicly available in the
Linux kernel.

Thanks,

- Alex