> Why this value of 10? I would go with 1, since we already reserve 1 credit for oplocks. If the reasoning is to have enough credits to send multiple lease/oplock acks, we should change the reserved count altogether. I think there could be some value in sending multiple lease break responses (ie allow oplock credits to be a few more than 1), but my main reasoning for this was to pick some number that was "safe" (allowing 10 oplock/lease-break credits while in flight count is non-zero is unlikely to be a problem) and would be unlikely to change existing behavior. My thinking was that today's code allows oplock credits to be above 1 (and keep growing in the server scenario you noticed) while multiple requests continue to be in flight - so there could potentially be a performance benefit during this period of high activity in having a few lease breaks in flight at one time and unlikely to hurt anything - but more importantly if we change the code to never allow oplock/lease credits to be above one we could (unlikely but possible) have subtle behavior changes that trigger a bug (since we would then have cases to at least some servers where we never have two lease breaks in flight). It seemed harmless to set the threshold to something slightly more than one (so multiple lease breaks in flight would still be possible and thus behavior would not change - but risk of credit starvation is gone). If you prefer - I could pick a number like 2 or 3 credits instead of 10. My intent was just to make it extremely unlikely that any behavior would change (but would still fix the possible credit starvation scenario) - so 2 or 3 would also probably be fine. On Tue, Jun 20, 2023 at 2:48 AM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > > On Tue, Jun 20, 2023 at 9:12 AM Steve French <smfrench@xxxxxxxxx> wrote: > > > > There were cases reported where servers will sometimes return more > > credits than requested on oplock break responses, which can lead to > > most of the credits being allocated for oplock breaks (instead of > > for normal operations like read and write) if number of SMB3 requests > > in flight always stays above 0 (the oplock and echo credits are > > rebalanced when in flight requests goes down to zero). > > > > If oplock credits gets unexpectedly large (e.g. ten is more than it > > would ever be expected to be) and in flight requests are greater than > > zero, then rebalance the oplock credits and regular credits (go > > back to reserving just one oplock credit. > > > > See attached > > > > -- > > Thanks, > > > > Steve > > Hi Steve, > > > If oplock credits gets unexpectedly large (e.g. ten is more than it > > would ever be expected to be) and in flight requests are greater than > > zero, then rebalance the oplock credits and regular credits (go > > back to reserving just one oplock crdit). > > Why this value of 10? I would go with 1, since we already reserve 1 > credit for oplocks. > If the reasoning is to have enough credits to send multiple > lease/oplock acks, we should > change the reserved count altogether. > > -- > Regards, > Shyam -- Thanks, Steve
