On Fri, Jan 04, 2019 at 09:35:47AM -0700, Jason Gunthorpe wrote: > 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? For proprietary device with proprietary protocol in proprietary network? Thanks > > Jason
Attachment:
signature.asc
Description: PGP signature
