qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] xen: Drop net_rx_ok


From: Chen Gang
Subject: Re: [Qemu-devel] [PATCH] xen: Drop net_rx_ok
Date: Tue, 28 Jul 2015 06:05:37 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 7/27/15 21:16, Stefan Hajnoczi wrote:
> On Mon, Jul 20, 2015 at 06:12:09PM +0100, Stefan Hajnoczi wrote:
>> On Thu, Jul 02, 2015 at 01:39:16PM +0100, Stefan Hajnoczi wrote:
>>> On Tue, Jun 30, 2015 at 10:42:37AM +0800, Fam Zheng wrote:
>>>> This is necessary because once we return false from .can_receive, we
>>>> need to flush the queue when the .can_receive conditions become true
>>>> again, (for example when more buffer is available).
>>>>
>>>> We can rely on net_rx_packet (which checks the same conditions) to drop
>>>> the packet if the device is not ready, so drop net_xen_info.can_receive.
>>>
>>> This patch changes behavior:
>>>
>>> Previously can_receive() false meant packets are queued.
>>>
>>> Now those same conditions result in net_rx_packet() returning -1, so
>>> packets are discarded.
>>>
>>> In order to keep the spirit of the queuing mechanism - where we tell a
>>> sender to hold off until more rx buffers become available - I think the
>>> following line in net_rx_packet() needs to be changed:
>>>
>>>   if (rc == rp || RING_REQUEST_CONS_OVERFLOW(&netdev->rx_ring, rc)) {
>>>       xen_be_printf(&netdev->xendev, 2, "no buffer, drop packet\n");
>>>       return -1;  <-- this should be changed to return 0
>>>   }
>>>
>>> That change assumes that net_event()'s flush is always called when the
>>> rx ring gets more free space.
>>>
>>> Any thoughts from Xen folks?
>>
>> Ping?
> 
> Need input from Xen developers.
> 
> Ping?
> 

In fact, I am not Xen folks. But I shall provide my idea for it, since
Cc to me.

For me, it is reasonable to use "return 0" instead of "return -1".

 - It completes the current API and keep compatible with the original
   usage. As return size, it needs to consider about all numbers (zero,
   negative, and positive numbers, like e.g. standard read/write API).

 - Comparing with all the other NetClientInfo.receive providers, some of
   them consider about it (e.g. virtio), others not (maybe each of them
   have their own reasons -- e.g. hardware will never generate 0 size).

Welcome any other members' ideas, suggestions and completions.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed



reply via email to

[Prev in Thread] Current Thread [Next in Thread]