[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