[PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[linhaifeng]

From: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

When failed to malloc buffer from mempool we just update last_used_idx but
not used->idx so after many times vhost thought have handle all packets
but virtio_net thought vhost have not handle all packets and will not
update avail->idx.

Signed-off-by: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 lib/librte_vhost/vhost_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 535c7a1..93a8fff 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id,
 		if (unlikely(m == NULL)) {
 			RTE_LOG(ERR, VHOST_DATA,
 				"Failed to allocate memory for mbuf.\n");
-			return entry_success;
+			goto finish;
 		}
 		seg_offset = 0;
 		seg_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
@@ -721,6 +721,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id,
 		entry_success++;
 	}
 
+finish:
 	rte_compiler_barrier();
 	vq->used->idx += entry_success;
 	/* Kick guest if required. */
-- 
1.8.5.2.msysgit.0

Re: [PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[Linhaifeng]

On 2015/3/20 11:54, linhaifeng wrote:
> From: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> When failed to malloc buffer from mempool we just update last_used_idx but
> not used->idx so after many times vhost thought have handle all packets
> but virtio_net thought vhost have not handle all packets and will not
> update avail->idx.
> 
> Signed-off-by: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
>  lib/librte_vhost/vhost_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
> index 535c7a1..93a8fff 100644
> --- a/lib/librte_vhost/vhost_rxtx.c
> +++ b/lib/librte_vhost/vhost_rxtx.c
> @@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id,
>  		if (unlikely(m == NULL)) {
>  			RTE_LOG(ERR, VHOST_DATA,
>  				"Failed to allocate memory for mbuf.\n");
> -			return entry_success;
> +			goto finish;

or use 'break' replace of 'goto' ?

>  		}
>  		seg_offset = 0;
>  		seg_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
> @@ -721,6 +721,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id,
>  		entry_success++;
>  	}
>  
> +finish:
>  	rte_compiler_barrier();
>  	vq->used->idx += entry_success;
>  	/* Kick guest if required. */
> 

-- 
Regards,
Haifeng

Re: [PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[Ouyang, Changchun]

> -----Original Message-----
> From: Linhaifeng [mailto:haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org]
> Sent: Friday, March 20, 2015 2:36 PM
> To: dev-VfR2kkLFssw@public.gmane.org
> Cc: Ouyang, Changchun; Xie, Huawei
> Subject: Re: [PATCH] lib/librte_vhost:fix can't send packet anymore after
> mempool is full again
> 
> 
> 
> On 2015/3/20 11:54, linhaifeng wrote:
> > From: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >
> > When failed to malloc buffer from mempool we just update last_used_idx
> > but not used->idx so after many times vhost thought have handle all
> > packets but virtio_net thought vhost have not handle all packets and
> > will not update avail->idx.
> >
> > Signed-off-by: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > ---
> >  lib/librte_vhost/vhost_rxtx.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_vhost/vhost_rxtx.c
> > b/lib/librte_vhost/vhost_rxtx.c index 535c7a1..93a8fff 100644
> > --- a/lib/librte_vhost/vhost_rxtx.c
> > +++ b/lib/librte_vhost/vhost_rxtx.c
> > @@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev,
> uint16_t queue_id,
> >  		if (unlikely(m == NULL)) {
> >  			RTE_LOG(ERR, VHOST_DATA,
> >  				"Failed to allocate memory for mbuf.\n");
> > -			return entry_success;
> > +			goto finish;
> 
> or use 'break' replace of 'goto' ?

Make sense, I can review if you make a v2 patch
Thanks
Changchun

Re: [PATCH] lib/librte_vhost:fix can't send packet anymore after mempool is full again

[Linhaifeng]

Hi, changchun & xie

I have modify the path with your suggestions.Please review.

Thank you.

On 2015/3/20 15:28, Ouyang, Changchun wrote:
> 
> 
>> -----Original Message-----
>> From: Linhaifeng [mailto:haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org]
>> Sent: Friday, March 20, 2015 2:36 PM
>> To: dev-VfR2kkLFssw@public.gmane.org
>> Cc: Ouyang, Changchun; Xie, Huawei
>> Subject: Re: [PATCH] lib/librte_vhost:fix can't send packet anymore after
>> mempool is full again
>>
>>
>>
>> On 2015/3/20 11:54, linhaifeng wrote:
>>> From: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>
>>> When failed to malloc buffer from mempool we just update last_used_idx
>>> but not used->idx so after many times vhost thought have handle all
>>> packets but virtio_net thought vhost have not handle all packets and
>>> will not update avail->idx.
>>>
>>> Signed-off-by: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>> ---
>>>  lib/librte_vhost/vhost_rxtx.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/librte_vhost/vhost_rxtx.c
>>> b/lib/librte_vhost/vhost_rxtx.c index 535c7a1..93a8fff 100644
>>> --- a/lib/librte_vhost/vhost_rxtx.c
>>> +++ b/lib/librte_vhost/vhost_rxtx.c
>>> @@ -609,7 +609,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev,
>> uint16_t queue_id,
>>>  		if (unlikely(m == NULL)) {
>>>  			RTE_LOG(ERR, VHOST_DATA,
>>>  				"Failed to allocate memory for mbuf.\n");
>>> -			return entry_success;
>>> +			goto finish;
>>
>> or use 'break' replace of 'goto' ?
> 
> Make sense, I can review if you make a v2 patch
> Thanks
> Changchun
> 
> 
> 
> 

-- 
Regards,
Haifeng