DPDK patches and discussions
 help / color / mirror / Atom feed
From: Linhaifeng <haifeng.lin@huawei.com>
To: "Xie, Huawei" <huawei.xie@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty
Date: Sat, 21 Mar 2015 10:25:26 +0800	[thread overview]
Message-ID: <550CD696.8070100@huawei.com> (raw)
In-Reply-To: <C37D651A908B024F974696C65296B57B0F3EC863@SHSMSX101.ccr.corp.intel.com>



On 2015/3/21 0:54, Xie, Huawei wrote:
> On 3/20/2015 6:47 PM, linhaifeng wrote:
>> From: Linhaifeng <haifeng.lin@huawei.com>
>>
>> If failed to alloc mbuf ring_size times the rx_q may be empty and can't
>> receive any packets forever because nb_used is 0 forever.
> Agreed. In current implementation, once VQ becomes empty, we have no
> chance to refill it again.
> The simple fix is, receive one and then refill one as other PMDs. Need

"Receive one and then refill one" also have this problem.If refill also
failed the VQ would be empty too.

> to consider which is best strategy in terms of performance in future.
> How did you find this? through code review or real workload?
>> so we should try to refill when nb_used is 0.After otherone free mbuf
>> we can restart to receive packets.
>>
>> Signed-off-by: Linhaifeng <haifeng.lin@huawei.com>
>> ---
>>  lib/librte_pmd_virtio/virtio_rxtx.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c b/lib/librte_pmd_virtio/virtio_rxtx.c
>> index 1d74b34..5c7e0cd 100644
>> --- a/lib/librte_pmd_virtio/virtio_rxtx.c
>> +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
>> @@ -495,7 +495,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
>>  		num = num - ((rxvq->vq_used_cons_idx + num) % DESC_PER_CACHELINE);
>>  
>>  	if (num == 0)
>> -		return 0;
>> +		goto refill;
>>  
>>  	num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
>>  	PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);
>> @@ -536,6 +536,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
>>  
>>  	rxvq->packets += nb_rx;
>>  
>> +refill:
>>  	/* Allocate new mbuf for the used descriptor */
>>  	error = ENOSPC;
>>  	while (likely(!virtqueue_full(rxvq))) {
> 
> 
> 

-- 
Regards,
Haifeng

  parent reply	other threads:[~2015-03-21  2:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 10:46 linhaifeng
2015-03-20 16:54 ` Xie, Huawei
2015-03-21  1:30   ` Linhaifeng
2015-03-21  2:25   ` Linhaifeng [this message]
2015-03-24 10:10     ` Xie, Huawei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550CD696.8070100@huawei.com \
    --to=haifeng.lin@huawei.com \
    --cc=dev@dpdk.org \
    --cc=huawei.xie@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).