[ofa-general] [PATCH RFC] RDMA: New Memory Extensions.
Steve Wise
swise at opengridcomputing.com
Wed May 14 20:46:57 PDT 2008
Roland Dreier wrote:
> > So you want the page size specified in the fast_reg_page_list as
> > opposed to when the page list is bound to the fast_reg mr (via
> > post_send)?
>
> It's kind of the same thing, since the fast_reg_page_list is part of the
> send work request... the structures you have at the moment are:
>
Yes, but I guess it makes more sense to specify it when you allocate the
page_list.
> > + struct {
> > + u64 iova_start;
> > + struct ib_fast_reg_page_list *page_list;
> > + int fbo;
> > + u32 length;
> > + int access_flags;
> > + struct ib_mr *mr;
>
> (side note... move this pointer up with the other pointers, so you don't
> end up with a hole in the structure due to alignment... or stick an int
> page_size in to fill the hole)
k
>
> > + } fast_reg;
>
> > +struct ib_fast_reg_page_list {
> > + struct ib_device *device;
> > + u64 *page_list;
> > + int page_list_len;
> > +};
>
> is page_list_len the maximum length of the page_list, or is it filled in
> by the consumer? The driver could figure out the length of the
> page_list for any given work request by looking at the MR length and the
> page_size I suppose.
The idea was that it was the current page_list length. But perhaps the
struct needs both current and max? Or maybe the struct contains the
max, and the actual length is passed in with the bind. Apps, however,
might need both anyway and providing a place to keep them in this struct
will help apps...
Steve.
More information about the general
mailing list