Re: [Qemu-devel] [PATCH 01/12] migration: Introduce announce parameters

[Vlad Yasevich]

On 06/01/2017 03:02 AM, Jason Wang wrote:
> 
> 
> On 2017年05月31日 02:57, Dr. David Alan Gilbert wrote:
>> * Vlad Yasevich (address@hidden) wrote:
>>> On 05/26/2017 12:03 AM, Jason Wang wrote:
>>>> On 2017年05月25日 02:05, Vladislav Yasevich wrote:
>>>>> Add parameters that control RARP/GARP announcement timeouts.
>>>>> The parameters structure is added to the QAPI and a qmp command
>>>>> is added to set/get the parameter data.
>>>>>
>>>>> Based on work by "Dr. David Alan Gilbert"<address@hidden>
>>>>>
>>>>> Signed-off-by: Vladislav Yasevich<address@hidden>
>>>> I think it's better to explain e.g under which condition do we need to 
>>>> tweak such
>>>> parameters.
>>>>
>>>> Thanks
>>>>
>>> OK.  I'll rip off what dgilbert wrote in his original series for the 
>>> description.
>>>
>>> Dave, if you have any text to add as to why migration might need to tweak 
>>> this, I'd
>>> appreciate it.
>> Pretty much what I originally said;  that the existing values
>> are arbitrary and fixed, and for systems with complex/sluggish
>> network reconfiguration systems they can be too slow.
>>
>> Dave
>>
> 
> I agree, but I'm not sure how much it can help in fact unless management can 
> set
> configuration specific parameters. And what we did here is best effort, 
> there's no
> guarantee that G(R)ARP packet can reach the destination.
> 

So, that's what the series allows.  If management knows something new, it can 
set
appropriate parameter values.  Additionally, the management is also free to 
trigger
additional announcements through the new commands.

I am starting to think that just for the sake of migration, exposing 
announce_self
interface to management might be sufficient.  Management, when it deems 
migration
complete, may use the interface to trigger announcements in addition to whatever
best effort QEMU may attempt itself.

Dave, would that be enough, or do the parameters still make sense?

Thanks
-vlad