On Wed, Dec 05, 2018 at 07:14:28PM +0000, Hefty, Sean wrote: > > >> As far as usnic, it seems like its the driver that has been > > forgotten about. > > >> I see 3 commits in 2018. I'm not saying it's important or not, > > that's > > >> another debate for another thread. > > > > > > There are alot more than three, and all of them are from non-Cisco > > > people trying to maintain this driver. Many are mine. > > > > > > This is not a plus, it shows why this approach is a burden on the > > rest > > > of the community. > > > > That's the point I was beating around the bush about. As a community > > we don't need any fire and forget drivers where it gets upstreamed and > > abandoned. > > usNIC is a very simple device. I'm not sure you can assume that it > isn't used or was forgotten just because it's done. I do know that > it is actively maintained on the user space side, even if it doesn't > need anything more from the kernel. The driver still had security bugs I had to fix. I'm not sure it follows our security model (I have this guess it actually needs CAP_NET_RAW) This is all bad. > I agree that exposing usNIC through verbs was wrong. However, as a > device, I don't see that it's that functionally different than QIB, > truescale, or hfi1. None of those are verbs devices, and throwing a > software verbs implementation over them doesn't really change that. The Linux standard that has evolved is that a common verbs driver can provide extensions beyond verbs through the driver private interface and still be 'drivers/infiniband' This makes sense in all cases so far as the extensions lean heavily on the core code to work properly, ie for addressing/security/etc. QIB/HFI are sort of marginal exceptions since their extension was not designed well as a proper extension, but that is more of a technical failing than a philosophical one. So at the userspace level psm/psm2/ucx may be distinct non-verbs things, but in the kernel we largely treat them as verbs extensions. > > Now if we do want to say a driver must support verbs it can't be > > wishy-washy. We should specify exactly the set of verbs that must be > > supported. The IBTA has the notion of some mandatory verbs right, so > > should that be the low bar? Should we whittle that down further? > > If you go this path, rename the subsystem to linux-verbs or > linux-ibverbs. It *is* the verbs subsystem - that is the only API it provides to the rest of the kernel today. > However, if the subsystem will support exposing non-verbs interfaces > (usnic, psm, psm2), then I disagree with placing a requirement that > the driver must also provide a software implementation of verbs over > it. This is what I mean when I talked about evolution earlier. If want to do non-verbs then do it right, not as a special QP hack like usnic did. Jason
