Re: [PATCH 1/1] qemu-kvm: virtio-net: Re-instate GSO code removed upstream

From: Glauber Costa <glommer@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Mark McLoughlin <markmc@redhat.com>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Glauber de Oliveira Costa <gcosta@redhat.com>
Subject: Re: [PATCH 1/1] qemu-kvm: virtio-net: Re-instate GSO code removed upstream
Date: Wed, 30 Sep 2009 08:24:35 -0300	[thread overview]
Message-ID: <20090930112435.GC5149@mothafucka.localdomain> (raw)
In-Reply-To: <4AC2F992.5000202@redhat.com>

On Wed, Sep 30, 2009 at 08:24:18AM +0200, Avi Kivity wrote:
> On 09/29/2009 10:45 PM, Mark McLoughlin wrote:
>> On Tue, 2009-05-05 at 09:56 +0100, Mark McLoughlin wrote:
>>    
>>> This commit:
>>>
>>>     commit 559a8f45f34cc50d1a60b4f67a06614d506b2e01
>>>     Subject: Remove stray GSO code from virtio_net (Mark McLoughlin)
>>>
>>> Removed some GSO code from upstream qemu.git, but it needs to
>>> be re-instated in qemu-kvm.git.
>>>
>>> Reported-by: Sridhar Samudrala<sri@us.ibm.com>
>>> Signed-off-by: Mark McLoughlin<markmc@redhat.com>
>>> ---
>>>   hw/virtio-net.c |    5 +++++
>>>   1 files changed, 5 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
>>> index ac8e030..e5d7add 100644
>>> --- a/hw/virtio-net.c
>>> +++ b/hw/virtio-net.c
>>> @@ -424,6 +424,11 @@ static int receive_filter(VirtIONet *n, const uint8_t *buf, int size)
>>>       if (n->promisc)
>>>           return 1;
>>>
>>> +#ifdef TAP_VNET_HDR
>>> +    if (tap_has_vnet_hdr(n->vc->vlan->first_client))
>>> +        ptr += sizeof(struct virtio_net_hdr);
>>> +#endif
>>> +
>>>       if (!memcmp(&ptr[12], vlan, sizeof(vlan))) {
>>>           int vid = be16_to_cpup((uint16_t *)(ptr + 14))&  0xfff;
>>>           if (!(n->vlans[vid>>  5]&  (1U<<  (vid&  0x1f))))
>>>      
>> I'm not sure[1] how we didn't notice, but this has been broken on the
>> stable-0.10 branch since 0.10.3; please apply there too
>>
>>    
>
> Thanks, we'll queue it on stable-0.10.
>
> Anthony/Glauber, is 0.10.7 in the works?  If not, we'll release it as  
> 0.10.6.1.
Since it is just one patch, I don't see a problem in anthony picking it directly
and making a new release.