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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
