From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <tkiely@Brocade.com>
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com
[67.231.152.113]) by dpdk.org (Postfix) with ESMTP id 5C8A45947
for <dev@dpdk.org>; Thu, 17 Dec 2015 10:22:35 +0100 (CET)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1])
by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id
tBH8UUUc030986; Thu, 17 Dec 2015 01:22:34 -0800
Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227])
by mx0b-000f0801.pphosted.com with ESMTP id 1yue2rhwfd-1
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Thu, 17 Dec 2015 01:22:34 -0800
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by
BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server
(TLS) id 15.0.1104.5; Thu, 17 Dec 2015 02:22:32 -0700
Received: from [10.252.48.20] (10.252.48.20) by EMEAWP-EXMB12.corp.brocade.com
(172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5;
Thu, 17 Dec 2015 10:22:29 +0100
To: "Xie, Huawei" <huawei.xie@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
References: <1447407013-6986-1-git-send-email-tkiely@brocade.com>
<C37D651A908B024F974696C65296B57B4B1B2353@SHSMSX101.ccr.corp.intel.com>
<C37D651A908B024F974696C65296B57B4C545F75@SHSMSX101.ccr.corp.intel.com>
From: Tom Kiely <tkiely@brocade.com>
Message-ID: <56727ECE.4050304@brocade.com>
Date: Thu, 17 Dec 2015 09:22:22 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <C37D651A908B024F974696C65296B57B4C545F75@SHSMSX101.ccr.corp.intel.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.252.48.20]
X-ClientProxiedBy: hq1wp-excas14.corp.brocade.com (10.70.38.103) To
EMEAWP-EXMB12.corp.brocade.com (172.29.11.86)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33,
0.0.0000
definitions=2015-12-16_09:2015-12-16,2015-12-16,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=2 phishscore=0
adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=7.0.1-1511060000 definitions=main-1512170149
Subject: Re: [dpdk-dev] [PATCH] virtio: fix rx ring descriptor starvation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 09:22:35 -0000
Hi,
Sorry for the delay. I have been occupied on another critical issue.
I'll look at this today.
Tom
On 12/17/2015 04:47 AM, Xie, Huawei wrote:
> On 11/26/2015 1:33 AM, Xie, Huawei wrote:
>> On 11/13/2015 5:33 PM, Tom Kiely wrote:
>>> If all rx descriptors are processed while transient
>>> mbuf exhaustion is present, the rx ring ends up with
>>> no available descriptors. Thus no packets are received
>>> on that ring. Since descriptor refill is performed post
>>> rx descriptor processing, in this case no refill is
>>> ever subsequently performed resulting in permanent rx
>>> traffic drop.
>>>
>>> Signed-off-by: Tom Kiely <tkiely@brocade.com>
>>> ---
>>> drivers/net/virtio/virtio_rxtx.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
>>> index 5770fa2..a95e234 100644
>>> --- a/drivers/net/virtio/virtio_rxtx.c
>>> +++ b/drivers/net/virtio/virtio_rxtx.c
>>> @@ -586,7 +586,8 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
>>> if (likely(num > DESC_PER_CACHELINE))
>>> num = num - ((rxvq->vq_used_cons_idx + num) % DESC_PER_CACHELINE);
>>>
>>> - if (num == 0)
>>> + /* Refill free descriptors even if no pkts recvd */
>>> + if (num == 0 && virtqueue_full(rxvq))
>> Should the return condition be that no used buffers and we have avail
>> descs in avail ring, i.e,
>> num == 0 && rxvq->vq_free_cnt != rxvq->vq_nentries
>>
>> rather than
>> num == 0 && rxvq->vq_free_cnt == 0
>> ?
> Tom:
> Any further progress?
>>> return 0;
>>>
>>> num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
>>> @@ -683,7 +684,8 @@ virtio_recv_mergeable_pkts(void *rx_queue,
>>>
>>> virtio_rmb();
>>>
>>> - if (nb_used == 0)
>>> + /* Refill free descriptors even if no pkts recvd */
>>> + if (nb_used == 0 && virtqueue_full(rxvq))
>>> return 0;
>>>
>>> PMD_RX_LOG(DEBUG, "used:%d\n", nb_used);