On Thu, Apr 4, 2024 at 4:37 AM Jiri Pirko <jiri@xxxxxxxxxxx> wrote: > > Wed, Apr 03, 2024 at 10:08:24PM CEST, alexander.duyck@xxxxxxxxx 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
