https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-12444 Lustre <p>Two flags of <b>rq_no_delay</b> and <b>rq_no_resend</b> might not be necessary. We don't have precise definitions and uages conditions for them to distinguish them.</p> <p>I think <b>rq_no_delay</b> means the request should quit and return whenever there is any possibility of being blocked, either it is caused by reconnection or other conditions. And <b>rq_no_resend</b> should always be set when <b>rq_no_delay</b> is set, which is true in a lot of places but not all. It is not clear why <b>rq_no_resend</b> is necessary. Even there is a case in which <b>rq_no_delay</b> is not suitable, a more precise flag or a better mechanism should be used.</p> LU-12444

Remove ambiguous request flag of no_resend

New Feature Minor Open Unresolved Li Xi Li Xi Mon, 17 Jun 2019 12:42:01 +0000 Mon, 17 Jun 2019 14:12:18 +0000 0 4 <p>Li Xi (lixi@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/35244" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35244</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-12444" title="Remove ambiguous request flag of no_resend" class="issue-link" data-issue-key="LU-12444">LU-12444</a> ptlrpc: remove no_resend flag<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 8ecd22a39c25365d54b7febb1a2b5eef7e3ccae9</p> <p>Li Xi,</p> <p>Thank you very much for diving in and trying this...</p> <p>IMHO, no_resend has a clear meaning - the RPC may be queued on the client, but it gets one chance to be sent and if it times out there is no reason to resend it. I don't think this is the same as "never" blocking an RPC for no_delay. What constitutes "blocking"? Local memory allocation, queue delay in the network, other?</p> <p>OK. Then "blocking" needs more detailed definition. But I think the use case of no_delay seems clear: quit whenever it hits problem/failure when trying to proceed, or seeing high possibility of problem/failure if proceed. So, if memory allocation failure, yes, no_delay request would quit. And if the request handler foresees high possibility of slow memory allocation or failure of memory allocation, no_delay request would quit too.</p> <blockquote><p> no_resend has a clear meaning - the RPC may be queued on the client, but it gets one chance to be sent and if it times out there is no reason to resend it.</p></blockquote> <p>This sounds like part of no_delay's functionality. I am wondering whether there is any possibility to re-use no_delay for (most of) the cases when no_resend is used. And I know there might be some cases when rq_no_delay is not suitable or not enough. And my attemption here is to check what these cases are. "req-&gt;rq_no_resend = req-&gt;rq_no_delay = 1" is written in a lot of places. So, I feel this might simplify the logic in general.</p> <p>At least, even cleaning up rq_no_resend is too complex to come true, we still need a patch adding some comments to explicitly explain the difference between these two flags to avoid future confusion.</p> Related LU-12378 Development Rank 1|i00ibz: Rank (Obsolete) 9223372036854775807