On Fri, Feb 19, 2016 at 03:03:26PM +0800, Yuanhan Liu wrote: > On Fri, Feb 19, 2016 at 02:11:36PM +0800, Tan, Jianfeng wrote: > > What I suggest here is to move user_send_rarp() to rte_vhost_dequeue_burst() > > using a flag to control, so that this arp packet can be broadcasted in its > > own L2 network. > > I have thought of that, too. It was given up because SEND_RARP request was > handled in different thread from rte_vhost_dequeue_burst(), leading to the > fact that the RARP packet will not be broadcasted immediately after migration > is done: it will be broadcasted only when rte_vhost_dequeue_burst() is > invoked. > > I was thinking the delay might be a problem. While thinking it twice, it > doesn't look like one then. As GUEST_ANNOUNCE is also broadcasted by > rte_vhost_dequeue_burst(); it's enqueued by guest kernel though. And > judging that we are polling mode driver, it won't be an issue then. > > So, thanks. I will give it a quick try; it should work.
It worked like a charm :) Thanks. --yliu