Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
On 10 May 2006, at 00:51, Chris Wright wrote: * Herbert Xu ([EMAIL PROTECTED]) wrote: Chris Wright [EMAIL PROTECTED] wrote: + netdev-features= NETIF_F_IP_CSUM; Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter would seem to be in fact easier for a virtual driver, no? That, I really don't know. Checksum offload was added late to the virtual transport and currently not enough info is carried to identify protocol checksum fields in arbitrary locations. When we rev the virtual interface, and include a proper checksum-offset field, we'll be able to switch to NETIF_F_HW_CSUM. -- Keir - 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.
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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 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.
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?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 Tuesday 09 May 2006 15:01, 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? I guess they don't trust user space. But the standard ipup script from iproute2 does this already so at least for modern distributions it should just work. -Andi - 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.
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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
[EMAIL PROTECTED] wrote on 05/09/2006 09:00:27 AM: 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. Then make a generic solution. VMWare supports migration, the Power virtualization will get around to it eventually. All will need something similar. So either make a common user-land tool, or (if you insist on incorrectly driving this into the kernel) add some kind of common hook to the TCP/IP stack. Dave Boutcher IBM Linux Technology Center - 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.
Chris Wright [EMAIL PROTECTED] wrote:
+ netdev-features= NETIF_F_IP_CSUM;
Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter
would seem to be in fact easier for a virtual driver, no?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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.
* Herbert Xu ([EMAIL PROTECTED]) wrote: Chris Wright [EMAIL PROTECTED] wrote: + netdev-features= NETIF_F_IP_CSUM; Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter would seem to be in fact easier for a virtual driver, no? That, I really don't know. thanks, -chris - 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
