On 06/01/2017 03:02 AM, Jason Wang wrote: > > > On 2017年05月31日 02:57, Dr. David Alan Gilbert wrote: >> * Vlad Yasevich (vyase...@redhat.com) 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"<dgilb...@redhat.com> >>>>> >>>>> Signed-off-by: Vladislav Yasevich<vyase...@redhat.com> >>>> 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