On Fri, Jan 04, 2019 at 12:31:21PM +0200, Gal Pressman wrote: > On 04-Jan-19 06:11, Jason Gunthorpe wrote: > > On Thu, Jan 03, 2019 at 06:32:56PM -0500, Doug Ledford wrote: > > > >>> The original point is still un-addressed. We, as a community, have > >>> identified usnic as a bad idea that does not belong in > >>> drivers/infiniband. This has been a pretty much universal position of > >>> everyone who has worked on the core RDMA stack. > >> > >> I'll generally agree with this. It turns out usnic is not so much about > >> access to a shared device with PD, QP, CQ, MR and AH support, but an > >> SRIOV network device attached to a process with minimal (but sufficient > >> I think) security measures to at least make sure that process can't > >> listen in on other traffic. From there, it's just UDP on a private > >> network adapter. > > > > EFA looks the same to me, except instead of UDP it is doing a bit > > more, but it still just datagram processing. There are no verbs here > > other than SEND and RECV. There is no RMA.. > > > > The functions usnic and EFA stub to EOPNOTSUPP/null look super similar > > to me. > > The stubs are there because of IB_MANDATORY_FUNC. Yes, because those functions are *MANDATORY* to be an actual verbs device :) That is another thing that should be revised for these no-kverbs things, I don't want to see stubs.. In fact seeing null in any mandatory function pointers is a good way to trigger the 'clients cannot be attached' behavior in your earlier RFC patch. > > I've never used usnic, is this true? It sure looks like it can > > allocate ucontexts dynamically?? I think that is what the vnic stuff > > is for?? Maybe the ucontext limit is pretty small, but there sure is > > alot of code here if the limit is just 1.. We also don't know the EFA > > ucontext limit ... > > There is no ucontext limit. Oh? EFA is sharing BAR pages between user processes? You have a security proof that is OK? Jason
