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:

quoted

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