Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Tue, May 09, 2006 at 09:55:33PM +1000, Herbert Xu wrote: Hi Chris: Chris Wright [EMAIL PROTECTED] wrote: +/** Send a packet on a net device to encourage switches to learn the + * MAC. We send a fake ARP request. + * + * @param dev device + * @return 0 on success, error code otherwise + */ +static int send_fake_arp(struct net_device *dev) I think we talked about this before. I don't see why Xen is so special that it needs its own gratuitous arp routine embedded in the driver. If this is needed at all (presumably for migration) then it should be performed by the management scripts which can send grat ARP packets just as easily. There's at least two reasons why having it in the driver is preferable: - synchronizing sending the fake ARP request with when the device is operational -- you really want to make this well synchronized to keep unreachability as short as possible, especially when doing live migration - anybody but the guest might not know (all) the MAC addresses for which to send a fake ARP request christian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Tue, May 09, 2006 at 11:01:05PM +1000, Herbert Xu wrote: Christian Limpach [EMAIL PROTECTED] wrote: There's at least two reasons why having it in the driver is preferable: - synchronizing sending the fake ARP request with when the device is operational -- you really want to make this well synchronized to keep unreachability as short as possible, especially when doing live migration - anybody but the guest might not know (all) the MAC addresses for which to send a fake ARP request Sure. However, what's there to stop you from doing this in user-space inside the guest? Possibly having to page in the process and switching to it would add to the live migration time. More importantly, having to install an additional program in the guest is certainly not very convenient. christian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Tue, May 09, 2006 at 11:26:03PM +1000, Herbert Xu wrote: Christian Limpach [EMAIL PROTECTED] wrote: Possibly having to page in the process and switching to it would add to the live migration time. More importantly, having to install an additional program in the guest is certainly not very convenient. Sorry I'm still not convinced. What's there to stop me from suspending my laptop to disk, moving it from port A to port B and resuming it? Wouldn't I be in exactly the same situation? By the same reasoning we'd be adding a gratuitous ARP routine to every single laptop network driver. It is the same situation except that in the laptop case you don't care that reconfiguring your network will take a second or a few. For live migration we're looking at network downtime from as low as 60ms to something like 210ms on a busy virtual machine. I'm not saying that a userspace solution wouldn't work but it would probably add a measurable delay to the network downtime during live migration. You might also find the following paper an interesting read: http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2005-migration-nsdi-pre.pdf christian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
