[linux-cifs-client] cleaning patches for smb_send and smb_send2

[Dave Kleikamp]

On Fri, 2008-12-19 at 07:06 -0500, Jeff Layton wrote:
> It looks like Linus is going to open the merge window fairly soon. I'd
> like to see if we can get to some sort of consensus on the attached
> patches. It makes no sense to me to have smb_send/sendv keep retrying
> in a loop on blocking sends. Those are just unnecessary wakeups when
> the machine could be doing something else useful.
> 
> The current point of contention is what an appropriate send timeout
> should be. My feeling is that it doesn't make sense to use different
> send timeouts for different calls. Sure, it may take longer to complete
> a write than a QPathInfo call, but that's not necessarily the case. If
> the server is hammered trying to satisfy writes, a QPathInfo call might
> take just as long. It's best IMO, to just have a single timeout.
> 
> The paramount thing to strive for here is consistency in the user's
> expectations. How would we explain that some calls may time out sooner
> than others? To do that is to make a judgement that some calls are
> more important than others. I don't think we can assume that, since
> that's highly dependent on the application.
> 
> Eventually, I'd like to see us drop the non-blocking send code
> altogether. IMO, "noblocksnd" and "noautotune" are not helpful mount
> options for users. A mount option that allows them to set the sndtimeo
> may be, but I think that's dependent on using a single send timeout.
> 
> Thoughts?

I agree with everything you've said.  I especially like the first patch.
It definitely simplifies the code.  You can add my acked-by to both
patches.

Acked-by: Dave Kleikamp <shaggy at linux.vnet.ibm.com>
-- 
David Kleikamp
IBM Linux Technology Center