patches for DPDK stable branches
 help / color / mirror / Atom feed
* [PATCH] kni: fix possible alloc_q starvation when mbufs are exhausted
@ 2022-11-09  5:13 Yangchao Zhou
  2022-11-09  6:04 ` [PATCH v2] " Yangchao Zhou
  0 siblings, 1 reply; 10+ messages in thread
From: Yangchao Zhou @ 2022-11-09  5:13 UTC (permalink / raw)
  To: dev; +Cc: Hemant, stable

In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
immediately. So kni_allocate_mbufs may be failed, but we don't know.

Even worse, when alloc_q is completely exhausted, kni_net_tx in
rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
called again, even if the mbufs are eventually freed.

In this patch, we always try to allocate mbufs for alloc_q.

Don't worry about alloc_q being allocated too many mbufs, in fact,
the old logic will gradually fill up alloc_q.
Also, the cost of more calls to kni_allocate_mbufs should be acceptable.

Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
Cc: Hemant@freescale.com
Cc: stable@dpdk.org

Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
---
 lib/kni/rte_kni.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 8ab6c47153..265c5262f7 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -634,9 +634,9 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num)
 {
 	unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
 
-	/* If buffers removed, allocate mbufs and then put them into alloc_q */
-	if (ret)
-		kni_allocate_mbufs(kni);
+	/* Always try to allocate mbufs for alloc_q to avoid starvation when
+	 * kni->pktmbuf_pool is exhausted. */
+	kni_allocate_mbufs(kni);
 
 	return ret;
 }
-- 
2.25.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v2] kni: fix possible alloc_q starvation when mbufs are exhausted
  2022-11-09  5:13 [PATCH] kni: fix possible alloc_q starvation when mbufs are exhausted Yangchao Zhou
@ 2022-11-09  6:04 ` Yangchao Zhou
  2022-11-09 16:39   ` Stephen Hemminger
  2022-12-30  4:23   ` [PATCH v3] " Yangchao Zhou
  0 siblings, 2 replies; 10+ messages in thread
From: Yangchao Zhou @ 2022-11-09  6:04 UTC (permalink / raw)
  To: dev; +Cc: Hemant, stable

In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
immediately. So kni_allocate_mbufs may be failed, but we don't know.

Even worse, when alloc_q is completely exhausted, kni_net_tx in
rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
called again, even if the mbufs are eventually freed.

In this patch, we always try to allocate mbufs for alloc_q.

Don't worry about alloc_q being allocated too many mbufs, in fact,
the old logic will gradually fill up alloc_q.
Also, the cost of more calls to kni_allocate_mbufs should be acceptable.

Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
Cc: Hemant@freescale.com
Cc: stable@dpdk.org

Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
---
 lib/kni/rte_kni.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 8ab6c47153..ea9a507de3 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -634,9 +634,11 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num)
 {
 	unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
 
-	/* If buffers removed, allocate mbufs and then put them into alloc_q */
-	if (ret)
-		kni_allocate_mbufs(kni);
+	/*
+	 * Always try to allocate mbufs for alloc_q to avoid starvation when
+	 * kni->pktmbuf_pool is exhausted.
+	 */
+	kni_allocate_mbufs(kni);
 
 	return ret;
 }
-- 
2.25.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] kni: fix possible alloc_q starvation when mbufs are exhausted
  2022-11-09  6:04 ` [PATCH v2] " Yangchao Zhou
@ 2022-11-09 16:39   ` Stephen Hemminger
  2022-11-11  9:12     ` Matt
  2022-12-30  4:23   ` [PATCH v3] " Yangchao Zhou
  1 sibling, 1 reply; 10+ messages in thread
From: Stephen Hemminger @ 2022-11-09 16:39 UTC (permalink / raw)
  To: Yangchao Zhou; +Cc: dev, Hemant, stable

On Wed,  9 Nov 2022 14:04:34 +0800
Yangchao Zhou <zhouyates@gmail.com> wrote:

> In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> immediately. So kni_allocate_mbufs may be failed, but we don't know.
> 
> Even worse, when alloc_q is completely exhausted, kni_net_tx in
> rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
> called again, even if the mbufs are eventually freed.
> 
> In this patch, we always try to allocate mbufs for alloc_q.
> 
> Don't worry about alloc_q being allocated too many mbufs, in fact,
> the old logic will gradually fill up alloc_q.
> Also, the cost of more calls to kni_allocate_mbufs should be acceptable.
> 
> Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
> Cc: Hemant@freescale.com
> Cc: stable@dpdk.org
> 
> Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>

Since fifo_get returning 0 (no buffers) is very common would this
change impact performance.

If the problem is pool draining might be better to make the pool
bigger.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] kni: fix possible alloc_q starvation when mbufs are exhausted
  2022-11-09 16:39   ` Stephen Hemminger
@ 2022-11-11  9:12     ` Matt
  2022-12-09 16:15       ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Matt @ 2022-11-11  9:12 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, Hemant, stable

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

On Thu, Nov 10, 2022 at 12:39 AM Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Wed,  9 Nov 2022 14:04:34 +0800
> Yangchao Zhou <zhouyates@gmail.com> wrote:
>
> > In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> > immediately. So kni_allocate_mbufs may be failed, but we don't know.
> >
> > Even worse, when alloc_q is completely exhausted, kni_net_tx in
> > rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
> > called again, even if the mbufs are eventually freed.
> >
> > In this patch, we always try to allocate mbufs for alloc_q.
> >
> > Don't worry about alloc_q being allocated too many mbufs, in fact,
> > the old logic will gradually fill up alloc_q.
> > Also, the cost of more calls to kni_allocate_mbufs should be acceptable.
> >
> > Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
> > Cc: Hemant@freescale.com
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
>
> Since fifo_get returning 0 (no buffers) is very common would this
> change impact performance.
>
It does add a little cost, but there is no extra mbuf allocation
and deallocation.

>
> If the problem is pool draining might be better to make the pool
> bigger.
>
Yes, using a larger pool can avoid this problem. But this may lead to
resource wastage and full resource calculation is a challenge for developers
as it involves to mempool caching mechanism, IP fragment cache,
ARP cache, NIC txq, other transit queue, etc.

The mbuf allocation failure may also occur on many NIC drivers,
but if the mbuf allocation fails, the mbuf is not taken out so that
it can be recovered after a retry later.
KNI currently does not have such a takedown and recovery mechanism.
It is also possible to consider implementing something similar to
the NIC driver, but with more changes and other overheads.

[-- Attachment #2: Type: text/html, Size: 2795 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] kni: fix possible alloc_q starvation when mbufs are exhausted
  2022-11-11  9:12     ` Matt
@ 2022-12-09 16:15       ` Ferruh Yigit
  0 siblings, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2022-12-09 16:15 UTC (permalink / raw)
  To: Matt, Stephen Hemminger; +Cc: dev, Hemant, stable

On 11/11/2022 9:12 AM, Matt wrote:
> 
> 
> On Thu, Nov 10, 2022 at 12:39 AM Stephen Hemminger
> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> 
>     On Wed,  9 Nov 2022 14:04:34 +0800
>     Yangchao Zhou <zhouyates@gmail.com <mailto:zhouyates@gmail.com>> wrote:
> 
>     > In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
>     > immediately. So kni_allocate_mbufs may be failed, but we don't know.
>     >
>     > Even worse, when alloc_q is completely exhausted, kni_net_tx in
>     > rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
>     > called again, even if the mbufs are eventually freed.
>     >
>     > In this patch, we always try to allocate mbufs for alloc_q.
>     >
>     > Don't worry about alloc_q being allocated too many mbufs, in fact,
>     > the old logic will gradually fill up alloc_q.
>     > Also, the cost of more calls to kni_allocate_mbufs should be
>     acceptable.
>     >
>     > Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
>     > Cc: Hemant@freescale.com <mailto:Hemant@freescale.com>
>     > Cc: stable@dpdk.org <mailto:stable@dpdk.org>
>     >
>     > Signed-off-by: Yangchao Zhou <zhouyates@gmail.com
>     <mailto:zhouyates@gmail.com>>
> 
>     Since fifo_get returning 0 (no buffers) is very common would this
>     change impact performance.
> 
> It does add a little cost, but there is no extra mbuf allocation
> and deallocation.
> 

It is common that 'rte_kni_rx_burst()' called in continuous loop, I
expect to try to fill alloc_q in each call impacts performance, even no
mbuf allocated at all.

> 
>     If the problem is pool draining might be better to make the pool
>     bigger.
> 
> Yes, using a larger pool can avoid this problem. But this may lead to
> resource wastage and full resource calculation is a challenge for developers
> as it involves to mempool caching mechanism, IP fragment cache,
> ARP cache, NIC txq, other transit queue, etc.
> 
> The mbuf allocation failure may also occur on many NIC drivers,
> but if the mbuf allocation fails, the mbuf is not taken out so that
> it can be recovered after a retry later.
> KNI currently does not have such a takedown and recovery mechanism.
> It is also possible to consider implementing something similar to
> the NIC driver, but with more changes and other overheads.

I agree this can cause starvation and recovery mechanism is missing,

Following may be an option, but still concerned about performance impact
and not sure about upstreaming it. Other solution can be to use larger
pool as Stephen suggested.

rte_kni_rx_burst()
	ret = kni_fifo_get()

	if (ret & kni_fifo_count(alloc_q) == 0)
		kni_allocate_mbufs()
	

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v3] kni: fix possible alloc_q starvation when mbufs are exhausted
  2022-11-09  6:04 ` [PATCH v2] " Yangchao Zhou
  2022-11-09 16:39   ` Stephen Hemminger
@ 2022-12-30  4:23   ` Yangchao Zhou
  2023-01-03 12:47     ` Ferruh Yigit
  1 sibling, 1 reply; 10+ messages in thread
From: Yangchao Zhou @ 2022-12-30  4:23 UTC (permalink / raw)
  To: dev; +Cc: stephen, ferruh.yigit, stable

In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
immediately. So kni_allocate_mbufs may be failed, but we don't know.

Even worse, when alloc_q is completely exhausted, kni_net_tx in
rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
called again, even if the mbufs are eventually freed.

In this patch, we try to allocate mbufs for alloc_q when it is empty.

According to historical experience, the performance bottleneck of KNI
is offen the usleep_range of kni thread in rte_kni.ko.
The check of kni_fifo_count is trivial and the cost should be acceptable.

Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
Cc: stable@dpdk.org

Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
---
 lib/kni/rte_kni.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 8ab6c47153..bfa6a001ff 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -634,8 +634,8 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num)
 {
 	unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
 
-	/* If buffers removed, allocate mbufs and then put them into alloc_q */
-	if (ret)
+	/* If buffers removed or alloc_q is empty, allocate mbufs and then put them into alloc_q */
+	if (ret || (kni_fifo_count(kni->alloc_q) == 0))
 		kni_allocate_mbufs(kni);
 
 	return ret;
-- 
2.25.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v3] kni: fix possible alloc_q starvation when mbufs are exhausted
  2022-12-30  4:23   ` [PATCH v3] " Yangchao Zhou
@ 2023-01-03 12:47     ` Ferruh Yigit
  2023-01-04 11:57       ` Matt
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2023-01-03 12:47 UTC (permalink / raw)
  To: Yangchao Zhou, dev; +Cc: stephen, stable

On 12/30/2022 4:23 AM, Yangchao Zhou wrote:
> In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> immediately. So kni_allocate_mbufs may be failed, but we don't know.
> 
> Even worse, when alloc_q is completely exhausted, kni_net_tx in
> rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
> called again, even if the mbufs are eventually freed.
> 
> In this patch, we try to allocate mbufs for alloc_q when it is empty.
> 
> According to historical experience, the performance bottleneck of KNI
> is offen the usleep_range of kni thread in rte_kni.ko.
> The check of kni_fifo_count is trivial and the cost should be acceptable.
> 

Hi Yangchao,

Are you observing any performance impact with this change in you use case?


> Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
> ---
>  lib/kni/rte_kni.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
> index 8ab6c47153..bfa6a001ff 100644
> --- a/lib/kni/rte_kni.c
> +++ b/lib/kni/rte_kni.c
> @@ -634,8 +634,8 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num)
>  {
>  	unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
>  
> -	/* If buffers removed, allocate mbufs and then put them into alloc_q */
> -	if (ret)
> +	/* If buffers removed or alloc_q is empty, allocate mbufs and then put them into alloc_q */
> +	if (ret || (kni_fifo_count(kni->alloc_q) == 0))
>  		kni_allocate_mbufs(kni);
>  
>  	return ret;


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v3] kni: fix possible alloc_q starvation when mbufs are exhausted
  2023-01-03 12:47     ` Ferruh Yigit
@ 2023-01-04 11:57       ` Matt
  2023-01-04 14:34         ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Matt @ 2023-01-04 11:57 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: dev, stephen, stable

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

Hi Ferruh,

In my case, the traffic is not large, so I can't see the impact.
I also tested under high load(>2Mpps with 2 DPDK cores and 2 kernel threads)
and found no significant difference in performance either.
I think the reason should be that it will not
run to 'kni_fifo_count(kni->alloc_q) == 0' under high load.

On Tue, Jan 3, 2023 at 8:47 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:

> On 12/30/2022 4:23 AM, Yangchao Zhou wrote:
> > In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> > immediately. So kni_allocate_mbufs may be failed, but we don't know.
> >
> > Even worse, when alloc_q is completely exhausted, kni_net_tx in
> > rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
> > called again, even if the mbufs are eventually freed.
> >
> > In this patch, we try to allocate mbufs for alloc_q when it is empty.
> >
> > According to historical experience, the performance bottleneck of KNI
> > is offen the usleep_range of kni thread in rte_kni.ko.
> > The check of kni_fifo_count is trivial and the cost should be acceptable.
> >
>
> Hi Yangchao,
>
> Are you observing any performance impact with this change in you use case?
>
>
> > Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
> > ---
> >  lib/kni/rte_kni.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
> > index 8ab6c47153..bfa6a001ff 100644
> > --- a/lib/kni/rte_kni.c
> > +++ b/lib/kni/rte_kni.c
> > @@ -634,8 +634,8 @@ rte_kni_rx_burst(struct rte_kni *kni, struct
> rte_mbuf **mbufs, unsigned int num)
> >  {
> >       unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
> >
> > -     /* If buffers removed, allocate mbufs and then put them into
> alloc_q */
> > -     if (ret)
> > +     /* If buffers removed or alloc_q is empty, allocate mbufs and then
> put them into alloc_q */
> > +     if (ret || (kni_fifo_count(kni->alloc_q) == 0))
> >               kni_allocate_mbufs(kni);
> >
> >       return ret;
>
>

[-- Attachment #2: Type: text/html, Size: 2851 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v3] kni: fix possible alloc_q starvation when mbufs are exhausted
  2023-01-04 11:57       ` Matt
@ 2023-01-04 14:34         ` Ferruh Yigit
  2023-03-11  9:16           ` Thomas Monjalon
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2023-01-04 14:34 UTC (permalink / raw)
  To: Matt; +Cc: dev, stephen, stable

On 1/4/2023 11:57 AM, Matt wrote:
> Hi Ferruh,
> 
> In my case, the traffic is not large, so I can't see the impact.
> I also tested under high load(>2Mpps with 2 DPDK cores and 2 kernel threads)
> and found no significant difference in performance either.
> I think the reason should be that it will not
> run to 'kni_fifo_count(kni->alloc_q) == 0' under high load.
> 

I agree, additional check most likely hit on the low bandwidth,
thanks for checking for performance impact.

> On Tue, Jan 3, 2023 at 8:47 PM Ferruh Yigit <ferruh.yigit@amd.com
> <mailto:ferruh.yigit@amd.com>> wrote:
> 
>     On 12/30/2022 4:23 AM, Yangchao Zhou wrote:
>     > In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
>     > immediately. So kni_allocate_mbufs may be failed, but we don't know.
>     >
>     > Even worse, when alloc_q is completely exhausted, kni_net_tx in
>     > rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
>     > called again, even if the mbufs are eventually freed.
>     >
>     > In this patch, we try to allocate mbufs for alloc_q when it is empty.
>     >
>     > According to historical experience, the performance bottleneck of KNI
>     > is offen the usleep_range of kni thread in rte_kni.ko.
>     > The check of kni_fifo_count is trivial and the cost should be
>     acceptable.
>     >
> 
>     Hi Yangchao,
> 
>     Are you observing any performance impact with this change in you use
>     case?
> 
> 
>     > Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
>     > Cc: stable@dpdk.org <mailto:stable@dpdk.org>
>     >
>     > Signed-off-by: Yangchao Zhou <zhouyates@gmail.com
>     <mailto:zhouyates@gmail.com>>

Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v3] kni: fix possible alloc_q starvation when mbufs are exhausted
  2023-01-04 14:34         ` Ferruh Yigit
@ 2023-03-11  9:16           ` Thomas Monjalon
  0 siblings, 0 replies; 10+ messages in thread
From: Thomas Monjalon @ 2023-03-11  9:16 UTC (permalink / raw)
  To: Matt; +Cc: stable, dev, stephen, Ferruh Yigit

04/01/2023 15:34, Ferruh Yigit:
> On 1/4/2023 11:57 AM, Matt wrote:
> > Hi Ferruh,
> > 
> > In my case, the traffic is not large, so I can't see the impact.
> > I also tested under high load(>2Mpps with 2 DPDK cores and 2 kernel threads)
> > and found no significant difference in performance either.
> > I think the reason should be that it will not
> > run to 'kni_fifo_count(kni->alloc_q) == 0' under high load.
> > 
> 
> I agree, additional check most likely hit on the low bandwidth,
> thanks for checking for performance impact.
> 
> > On Tue, Jan 3, 2023 at 8:47 PM Ferruh Yigit <ferruh.yigit@amd.com
> > <mailto:ferruh.yigit@amd.com>> wrote:
> > 
> >     On 12/30/2022 4:23 AM, Yangchao Zhou wrote:
> >     > In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> >     > immediately. So kni_allocate_mbufs may be failed, but we don't know.
> >     >
> >     > Even worse, when alloc_q is completely exhausted, kni_net_tx in
> >     > rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
> >     > called again, even if the mbufs are eventually freed.
> >     >
> >     > In this patch, we try to allocate mbufs for alloc_q when it is empty.
> >     >
> >     > According to historical experience, the performance bottleneck of KNI
> >     > is offen the usleep_range of kni thread in rte_kni.ko.
> >     > The check of kni_fifo_count is trivial and the cost should be
> >     acceptable.
> >     >
> > 
> >     Hi Yangchao,
> > 
> >     Are you observing any performance impact with this change in you use
> >     case?
> > 
> > 
> >     > Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
> >     > Cc: stable@dpdk.org <mailto:stable@dpdk.org>
> >     >
> >     > Signed-off-by: Yangchao Zhou <zhouyates@gmail.com
> >     <mailto:zhouyates@gmail.com>>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

Applied, thanks.



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-03-11  9:16 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-09  5:13 [PATCH] kni: fix possible alloc_q starvation when mbufs are exhausted Yangchao Zhou
2022-11-09  6:04 ` [PATCH v2] " Yangchao Zhou
2022-11-09 16:39   ` Stephen Hemminger
2022-11-11  9:12     ` Matt
2022-12-09 16:15       ` Ferruh Yigit
2022-12-30  4:23   ` [PATCH v3] " Yangchao Zhou
2023-01-03 12:47     ` Ferruh Yigit
2023-01-04 11:57       ` Matt
2023-01-04 14:34         ` Ferruh Yigit
2023-03-11  9:16           ` Thomas Monjalon

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).