On Fri, Aug 15, 2008 at 02:47:12PM -0500, Anthony Liguori wrote:
+static void work_around_broken_dhclient(struct virtio_net_hdr *hdr,
+const uint8_t *buf, size_t size)
+{
+if ((hdr-flags VIRTIO_NET_HDR_F_NEEDS_CSUM) /* missing csum */
+
On Wednesday 20 August 2008 01:05:55 Chris Wedgwood wrote:
On Tue, Aug 19, 2008 at 07:10:44PM +1000, Rusty Russell wrote:
We need both. CSUM2 is the new virtio-level feature.
Perhaps that's what I'm misisng. How is this different to CSUM?
Because current guests which say they can handle
On Tuesday 19 August 2008 15:17:08 Herbert Xu wrote:
On Mon, Aug 18, 2008 at 10:13:55PM -0700, Chris Wedgwood wrote:
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented short lifetime (if it
really must go in)?
All we need is
Rusty Russell wrote:
On Monday 18 August 2008 21:44:25 Herbert Xu wrote:
On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote:
Isn't that turned on automatically for real hardware? And what's to
prevent a broken dhclient together with the (presumably) hacked up
initscripts that
On Tuesday 19 August 2008 15:28:40 Chris Wedgwood wrote:
On Tue, Aug 19, 2008 at 03:17:08PM +1000, Herbert Xu wrote:
All we need is a simple toggle to disable checksum offload. Every
NIC that offers receive checksum offload allows it to be disabled.
virtio shouldn't be any different.
So
On Tue, Aug 19, 2008 at 07:08:23PM +1000, Rusty Russell wrote:
Not really. We could extend the protocol, but that's currently how feature
negotiation works: you can't do it while the device is live. That seemed
simplest. I learnt from Xen :)
(Of course, we don't need to *disable* it,
Anthony Liguori wrote:
I'd still like a way to disable it from the host. Even when it does
nothing it will force the header into the host cache, which may be
different from the guest cache.
It's already in the host cache as we don't have a zero copy API right
now.
I'm thinking of the
With the latest GSO/csum offload patches, any guest using an unpatched version
of dhclient (any Ubuntu guest, for instance), will no longer be able to get
a DHCP address.
dhclient is actually at fault here. It uses AF_PACKET to receive DHCP responses
but does not check auxdata to see if the
Anthony Liguori wrote:
With the latest GSO/csum offload patches, any guest using an unpatched version
of dhclient (any Ubuntu guest, for instance), will no longer be able to get
a DHCP address.
dhclient is actually at fault here. It uses AF_PACKET to receive DHCP responses
but does not check
On Tue, Aug 19, 2008 at 07:10:44PM +1000, Rusty Russell wrote:
We need both. CSUM2 is the new virtio-level feature.
Perhaps that's what I'm misisng. How is this different to CSUM?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
Rusty Russell wrote:
On Tuesday 19 August 2008 15:17:08 Herbert Xu wrote:
On Mon, Aug 18, 2008 at 10:13:55PM -0700, Chris Wedgwood wrote:
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented short lifetime (if it
really must
Anthony Liguori wrote:
With the latest GSO/csum offload patches, any guest using an unpatched version
of dhclient (any Ubuntu guest, for instance), will no longer be able to get
a DHCP address.
dhclient is actually at fault here. It uses AF_PACKET to receive DHCP responses
but does not check
Herbert Xu wrote:
On Mon, Aug 18, 2008 at 02:06:46PM +0300, Avi Kivity wrote:
I still think that having the guests tell us that they can handle
it is the safest and most efficient way to proceed.
I thought this is a userspace problem? Can we fix this in the guest kernel?
On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote:
Isn't that turned on automatically for real hardware? And what's to
prevent a broken dhclient together with the (presumably) hacked up
initscripts that call ethtool?
Well the idea is that only a fixed guest would even know about
On Monday 18 August 2008 21:44:25 Herbert Xu wrote:
On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote:
Isn't that turned on automatically for real hardware? And what's to
prevent a broken dhclient together with the (presumably) hacked up
initscripts that call ethtool?
Well the
On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote:
For those not following closely: We already have a method for the
guest to accept or reject features. Our problem is that the guest
is already accepting the CSUM feature: but one critical userspace
app (dhcp-client) can't
On Tuesday 19 August 2008 13:17:57 Chris Wedgwood wrote:
On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote:
For those not following closely: We already have a method for the
guest to accept or reject features. Our problem is that the guest
is already accepting the CSUM feature:
On Tue, Aug 19, 2008 at 02:41:01PM +1000, Rusty Russell wrote:
They need to do both. This way if they don't, it still works, but
networking is at a penalty (no CSUM offload).
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented
On Mon, Aug 18, 2008 at 10:13:55PM -0700, Chris Wedgwood wrote:
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented short lifetime (if it
really must go in)?
All we need is a simple toggle to disable checksum offload. Every
NIC
On Tue, Aug 19, 2008 at 03:17:08PM +1000, Herbert Xu wrote:
All we need is a simple toggle to disable checksum offload. Every
NIC that offers receive checksum offload allows it to be disabled.
virtio shouldn't be any different.
So why CSUM2 and not an ethtool interface then?
--
To
20 matches
Mail list logo
