From: Ben Hutchings bhutchi...@solarflare.com
Date: Thu, 7 Feb 2013 22:31:35 +
On Thu, 2013-02-07 at 23:33 +0200, Michael S. Tsirkin wrote:
We might want to add code to forward LRO status from macvlan
(not macvtap) back to the lowerdev, so that setting up forwarding
from macvlan disables
On Thu, Feb 07, 2013 at 11:25:13AM +0800, Cong Wang wrote:
On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote:
At the moment, macvtap crashes are observed if macvtap is attached
to an interface with LRO enabled.
The crash in question is BUG() in macvtap_skb_to_vnet_hdr.
This happens because
On Wed, 2013-02-06 at 19:18 -0800, Eric Dumazet wrote:
On Wed, 2013-02-06 at 23:34 +, Ben Hutchings wrote:
If we want to allow forwarding from LRO then net/ipv4/inet_lro.c also
needs to set gso_type.
Then, what is dev_disable_lro() purpose ?
The purpose was to disable LRO when
From: Ben Hutchings bhutchi...@solarflare.com
Date: Thu, 7 Feb 2013 16:20:46 +
If the consensus is still that we must preserve packets exactly (aside
from the usual modifications by IP routers) then LRO should be disabled
on all devices for which forwarding is enabled.
I believe this is
On Thu, 2013-02-07 at 23:33 +0200, Michael S. Tsirkin wrote:
On Thu, Feb 07, 2013 at 01:14:20PM -0500, David Miller wrote:
From: Ben Hutchings bhutchi...@solarflare.com
Date: Thu, 7 Feb 2013 16:20:46 +
If the consensus is still that we must preserve packets exactly (aside
from
On Thu, 2013-02-07 at 01:02 +0200, Michael S. Tsirkin wrote:
At the moment, macvtap crashes are observed if macvtap is attached
to an interface with LRO enabled.
The crash in question is BUG() in macvtap_skb_to_vnet_hdr.
This happens because several drivers set gso_size but not gso_type
in
On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote:
At the moment, macvtap crashes are observed if macvtap is attached
to an interface with LRO enabled.
The crash in question is BUG() in macvtap_skb_to_vnet_hdr.
This happens because several drivers set gso_size but not gso_type
in incoming
