[openib-general] [PATCH 1/2] mthca support for max_map_per_fmr device attribute

[Or Gerlitz]

Roland Dreier wrote:
>     Or> When "requests" come fast enough, there's a window in time
>     Or> when there's an unmapping of N FMRs running at batch, but out
>     Or> of the remaining N FMRs some are already dirty and can't be
>     Or> used to serve a credit. So the app fails temporally... So,
>     Or> setting the watermark to 0.5N might solve this, but since
>     Or> enlarging the number of remaps is trivial, i'd like to do it
>     Or> first.
> 
> I don't quite understand how increasing the max remap count really
> helps you that much.  Increasing it would just make this failure less
> frequent, but it would still occur, right?

Increasing the max remap count --really-- helps me b/c it takes >> time 
for free FMRs to become dirty, and this window is enough for the batch 
unmap to complete, so practically there are always free N FMRs with the 
scheme suggested above (allocate 2N with watermark at N, publish N to 
upper layers)

Indeed, the code can not --count-- on that, so when iSER get -EAGAIN 
return code from ib_fmr_pool_map_phys() it would try later. The current 
retry scheme is just trying over and over (you can not see it easily 
from the iser code, its related to the interaction with libiscsi), i 
have on my TODO an item to register a flush callback with the pool, 
suspend the iser TX flow when getting EAGAIN from fmr_map and resume TX 
from the flush callback.

Or.