RE: Local dma key and reserved l_key usage in mad

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Weiny, Ira [mailto:ira.weiny@xxxxxxxxx]
> Sent: Friday, November 30, 2018 4:21 AM
> To: Jason Gunthorpe <jgg@xxxxxxxx>; Syed Syed <SYEDS@xxxxxxxxxx>
> Cc: linux-rdma@xxxxxxxxxxxxxxx
> Subject: RE: Local dma key and reserved l_key usage in mad
> 
> >
> > On Thu, Nov 29, 2018 at 11:40:32AM +0000, Syed Syed wrote:
> > > Hi
> > >     Just wanted to cross-check with the list on these.
> > >  Is it always the case that the work requests presented on QP1(mad)
> > > shall have only "physical address" owing to the fact that the l_key
> > > associated  is reserved l_key(or local_dma_key)(from 10.6.4.3.2 of the
> spec)?
> > >  But is it mandatory that the consumer shall present memory from
> reserved
> > l_key on QP1?
> > > Is there a use case where normally registered memory(l_key)  (and
> > > associated virtual address instead of physical) can be used in QP1 work
> > request?
> >
> > As far as I know QP0&1 is no different from any other QP and can use any
> > appropriate lkey.
> 
> Agreed.
Ok. No, I was confused, since within kernel, in mad layer the wr is comprised of 
dma addr (in sg_list), whereas user space verbs present memory with virtual address.
Still if someone can confirm, is local_dma_key conceptually referring to reserved l_key (10.6.4.3.2) 
of the spec? Also that reserved l_key always assumed to be referring to physical address.

> 
> However, what is the end goal?  GSI traffic can run over standard UD QPs and
> if the use case is for user space applications to send/recv GSI's then that may
> be a better option.

ok.
> 
> Ira
> 
> >
> > Jason





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux