> 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. Given the discussion going on in the thread "mlx5 ConnectX control misc driver", you also plan to show you don't need such a misc driver? Andrew
