> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Chuck Lever
> Sent: Tuesday, July 14, 2015 1:47 PM
> To: Steve Wise
> Cc: Christoph Hellwig; Doug Ledford; [email protected]; Sagi Grimberg; Or 
> Gerlitz; [email protected]; linux-rdma; Eli Cohen;
target-
> [email protected]
> Subject: Re: [PATCH V5 5/5] RDMA/isert: Limit read depth based on the device 
> max_sge_rd capability
> 
> 
> On Jul 14, 2015, at 11:49 AM, Steve Wise <[email protected]> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: 'Christoph Hellwig' [mailto:[email protected]]
> >> Sent: Tuesday, July 14, 2015 10:42 AM
> >> To: Steve Wise
> >> Cc: 'Christoph Hellwig'; Chuck Lever; [email protected]; 
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected]; 
> >> [email protected]
> >> Subject: Re: [PATCH V5 5/5] RDMA/isert: Limit read depth based on the 
> >> device max_sge_rd capability
> >>
> >> On Tue, Jul 14, 2015 at 09:41:00AM -0500, Steve Wise wrote:
> >>>> Btw, any hance to make the NFS client use these values as well instead
> >>>> of the current rdma_read_max_sge() hack?
> >>>
> >>> Chuck, can you add this to your cleanup list?
> >>
> >> It would be useful to add this to your series so we can get rid of
> >> it for the next merge window instead of introducing a depenency that
> >> would defer it to the next merge window.
> >
> > Ok, I will do this.
> 
> Steve, can you review v2 of the nfs-rdma-for-4.3 series I posted
> yesterday? Specifically:
> 
>   
> http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=commit;h=6abafb636e03fbb7f93a26796223833581a70190
> 
> Which changes the way xprtrdma uses max_sge.
> 

Sure, but xprtrdma doesn't issue reads, so max_sge_rd isn't needed.  The change 
Christoph wants is actually in svcrdma.  I will
change the server to use max_sge_rd instead of rdma_cap_read_multi_sge().





--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to