From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tucker Subject: Re: [ewg] nfsrdma fails to write big file, Date: Wed, 24 Feb 2010 16:13:44 -0600 Message-ID: <4B85A498.1030708@opengridcomputing.com> References: <9FA59C95FFCBB34EA5E42C1A8573784F02662E58@mtiexch01.mti.com> <4B82D1B4.2030902@opengridcomputing.com> <9FA59C95FFCBB34EA5E42C1A8573784F02662EA8@mtiexch01.mti.com> <9FA59C95FFCBB34EA5E42C1A8573784F02663166@mtiexch01.mti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Roland Dreier Cc: Vu Pham , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mahesh Siddheshwar , ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org List-Id: linux-rdma@vger.kernel.org Roland Dreier wrote: > > + /* > > + * Add room for frmr register and invalidate WRs > > + * Requests sometimes have two chunks, each chunk > > + * requires to have different frmr. The safest > > + * WRs required are max_send_wr * 6; however, we > > + * get send completions and poll fast enough, it > > + * is pretty safe to have max_send_wr * 4. > > + */ > > + ep->rep_attr.cap.max_send_wr *= 4; > > Seems like a bad design if there is a possibility of work queue > overflow; if you're counting on events occurring in a particular order > or completions being handled "fast enough", then your design is going to > fail in some high load situations, which I don't think you want. > > I agree. It's basically a time bomb. A bump in the work flow and you'll overflow the CQ. Thanks for finding the bug though Vu. > - R. > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html