[dm-devel] dm-delay: Add a message to change delay

[Andy Grover]

On 09/01/2015 06:09 AM, Mike Snitzer wrote:
> On Tue, Sep 01 2015 at  8:14am -0400,
> Vivek Goyal <vgoyal at redhat.com> wrote:
>
>> On Mon, Aug 31, 2015 at 10:02:33PM -0700, Andy Grover wrote:
>>> On 08/31/2015 07:05 PM, Vivek Goyal wrote:
>>>> On Mon, Aug 31, 2015 at 02:24:36PM -0700, Andy Grover wrote:
>>>>> This enables runtime modification of the read and write delay values.
>>>>>
>>>>> Make sure if the delay time is reduced to flush currently-delayed
>>>>> bios first, to maintain ordering.
>>>>>
>>>>> Signed-off-by: Andy Grover <agrover at redhat.com>
>>>>> ---
>>>>>   Documentation/device-mapper/delay.txt |  8 +++++++
>>>>>   drivers/md/dm-delay.c                 | 42 +++++++++++++++++++++++++++++++++++
>>>>>   2 files changed, 50 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/device-mapper/delay.txt b/Documentation/device-mapper/delay.txt
>>>>> index 15adc55..9e80751 100644
>>>>> --- a/Documentation/device-mapper/delay.txt
>>>>> +++ b/Documentation/device-mapper/delay.txt
>>>>> @@ -10,6 +10,14 @@ Parameters:
>>>>>   With separate write parameters, the first set is only used for reads.
>>>>>   Delays are specified in milliseconds.
>>>>>
>>>>> +Message Interface
>>>>> +-----------------
>>>>> +The delay target will accept a message of the following format:
>>>>> +
>>>>> +set_delay <read_delay> [<write_delay>]
>>>>> +
>>>>
>>>> Hi Andy,
>>>>
>>>> So if I want to change only write_delay and keep read_delay same, how do
>>>> I do that. Do I have to keep track of existing delay values in user space
>>>> and pass same value in read_delay to achieve this.
>>>>
>>>> Thanks
>>>> Vivek
>>>
>>> Hi Vivek,
>>>
>>> Yes I suppose userspace would either need to remember read_delay so as to
>>> not change it while setting write_delay, or I guess it could read the
>>> existing values by getting table status before sending the message. Is this
>>> reasonable, or do you think it would be better to, say, have separate
>>> messages for setting the two values, or some other message style?
>>
>> Ideally I think we should have those --key=value type of arguments which
>> we don't have yet. So that option is not feasible I guess.
>>
>> If latest values are readable from status, then I think single message
>> sounds reasoanble to me.
>
> As Zdenek already effectively said: there is no need for this patch.
> You don't need to use a message when a table reload would suffice to
> change the parameter that is already passed on the table ctr.
>
> Any layer that would be trained to send a message can just as easily be
> trained to reload the table to achieve the same result.

Ah I see. Thanks for the explanations. Noflush suspend & table reload is 
better for this.

Regards -- Andy