[rds-devel] Re: The meaning of MR invalidation

[Richard Frank]

Just to be sure I'm on the same page..

We should not cache and "re-use keys" - we always want a fresh key (seqn 
bumped) for every I/O (get_mr).

When we invalidate we want all prior "free'd" keys to be invalid - not 
the current set of I/Os - which is why we want a fresh key on every I/O. 
The invalidate (sync_tpt) affects operations for all free'd keys.

Assuming multiple I/Os - each with a different key - are issued to the 
same memory - even with a fresh key on every I/O - without an 
intervening invalidate - it is possible for the prior I/O to arrive 
which could result in corruption.

It's up to the app to decide if an invalidate of prior I/Os (keys) is 
required - based on the apps protocol.


Olaf Kirch wrote:
> On Friday 08 February 2008 15:32, Richard Frank wrote:
>   
>>> We could make this a little more robust I guess by also freeing MRs
>>> when the application asks for an invalidate. At least the mthca
>>> driver seems to generate unique R_Keys (the top bits of the R_Key
>>> are used as a kind of counter, so we'd really have to cycle through
>>> 4 billion MRs before getting the same R_Key).
>>>
>>>   
>>>       
>> Yes - this is what we want.
>>     
>
> Okay. It'll allow me to remove quite a bit of code from the pool code,
> too.
>
> Olaf
>