diff mbox series

[v1] net/tap: fix blocked rx packets error

Message ID 20190902114310.15928-1-marcinx.smoczynski@intel.com (mailing list archive)
State Superseded, archived
Delegated to: Ferruh Yigit
Headers
Series [v1] net/tap: fix blocked rx packets error |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/iol-dpdk_compile_spdk success Compile Testing PASS
ci/iol-dpdk_compile success Compile Testing PASS
ci/iol-dpdk_compile_ovs success Compile Testing PASS
ci/intel-Performance success Performance Testing PASS
ci/mellanox-Performance success Performance Testing PASS

Commit Message

Marcin Smoczynski Sept. 2, 2019, 11:43 a.m. UTC 
  When OS sends more packets than are beaing read with a single
'rte_eth_rx_burst' call, rx packets are getting stucked in the tap pmd
and are unable to receive, because trigger_seen is getting updated
and consecutive calls are not getting any packets.

Do not update trigger_seen unless less than a max number of packets were
received allowing next call to receive the rest.

Fixes: a0d8e807d9 ("net/tap: add Rx trigger")
Cc: stable@dpdk.org

Tested-by: Mariusz Drost <mariuszx.drost@intel.com>
Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
---
 drivers/net/tap/rte_eth_tap.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Ananyev, Konstantin Sept. 3, 2019, 1:15 p.m. UTC | #1 
> -----Original Message-----
> From: Smoczynski, MarcinX
> Sent: Monday, September 2, 2019 12:43 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Wiles, Keith <keith.wiles@intel.com>; adrien.mazarguil@6wind.com
> Cc: dev@dpdk.org; stable@dpdk.org; Smoczynski, MarcinX <marcinx.smoczynski@intel.com>; Drost, MariuszX <mariuszx.drost@intel.com>
> Subject: [PATCH v1] net/tap: fix blocked rx packets error
> 
> When OS sends more packets than are beaing read with a single
> 'rte_eth_rx_burst' call, rx packets are getting stucked in the tap pmd
> and are unable to receive, because trigger_seen is getting updated
> and consecutive calls are not getting any packets.
> 
> Do not update trigger_seen unless less than a max number of packets were
> received allowing next call to receive the rest.
> 
> Fixes: a0d8e807d9 ("net/tap: add Rx trigger")
> Cc: stable@dpdk.org
> 
> Tested-by: Mariusz Drost <mariuszx.drost@intel.com>
> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
> ---
>  drivers/net/tap/rte_eth_tap.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 64bd04911..60121ae56 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -353,8 +353,7 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> 
>  	if (trigger == rxq->trigger_seen)
>  		return 0;
> -	if (trigger)
> -		rxq->trigger_seen = trigger;
> +
>  	process_private = rte_eth_devices[rxq->in_port].process_private;
>  	rte_compiler_barrier();
>  	for (num_rx = 0; num_rx < nb_pkts; ) {
> @@ -433,6 +432,9 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>  	rxq->stats.ipackets += num_rx;
>  	rxq->stats.ibytes += num_rx_bytes;
> 
> +	if (trigger && num_rx < nb_pkts)
> +		rxq->trigger_seen = trigger;
> +
>  	return num_rx;
>  }
> 
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Tested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

> 2.17.1
Gavin Hu Sept. 5, 2019, 5:43 a.m. UTC | #2 
HI Marcin,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Marcin Smoczynski
> Sent: Monday, September 2, 2019 7:43 PM
> To: konstantin.ananyev@intel.com; keith.wiles@intel.com;
> adrien.mazarguil@6wind.com
> Cc: dev@dpdk.org; stable@dpdk.org; Marcin Smoczynski
> <marcinx.smoczynski@intel.com>; Mariusz Drost
> <mariuszx.drost@intel.com>
> Subject: [dpdk-dev] [PATCH v1] net/tap: fix blocked rx packets error
>
> When OS sends more packets than are beaing read with a single
s/ beaing/being

> 'rte_eth_rx_burst' call, rx packets are getting stucked in the tap pmd
> and are unable to receive, because trigger_seen is getting updated
> and consecutive calls are not getting any packets.
>
> Do not update trigger_seen unless less than a max number of packets were
> received allowing next call to receive the rest.
>
> Fixes: a0d8e807d9 ("net/tap: add Rx trigger")
> Cc: stable@dpdk.org
>
> Tested-by: Mariusz Drost <mariuszx.drost@intel.com>
> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
> ---
>  drivers/net/tap/rte_eth_tap.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 64bd04911..60121ae56 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -353,8 +353,7 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
>
>       if (trigger == rxq->trigger_seen)
>               return 0;
> -     if (trigger)
> -             rxq->trigger_seen = trigger;
> +
>       process_private = rte_eth_devices[rxq->in_port].process_private;
>       rte_compiler_barrier();
I see this compiler barrier was added together with the above "rxq->trigger_seen = trigger", should it be removed or moved together downwards?

>       for (num_rx = 0; num_rx < nb_pkts; ) {
> @@ -433,6 +432,9 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
>       rxq->stats.ipackets += num_rx;
>       rxq->stats.ibytes += num_rx_bytes;
>
> +     if (trigger && num_rx < nb_pkts)
> +             rxq->trigger_seen = trigger;
> +
>       return num_rx;
>  }
>
> --
> 2.17.1

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Marcin Smoczynski Sept. 6, 2019, 8:48 a.m. UTC | #3 
> -----Original Message-----
> From: Gavin Hu (Arm Technology China) [mailto:Gavin.Hu@arm.com]
> Sent: Thursday, September 5, 2019 7:44 AM
> To: Smoczynski, MarcinX <marcinx.smoczynski@intel.com>; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>; Wiles, Keith
> <keith.wiles@intel.com>; adrien.mazarguil@6wind.com
> Cc: dev@dpdk.org; stable@dpdk.org; Drost, MariuszX
> <mariuszx.drost@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v1] net/tap: fix blocked rx packets error
> 
> HI Marcin,
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Marcin Smoczynski
> > Sent: Monday, September 2, 2019 7:43 PM
> > To: konstantin.ananyev@intel.com; keith.wiles@intel.com;
> > adrien.mazarguil@6wind.com
> > Cc: dev@dpdk.org; stable@dpdk.org; Marcin Smoczynski
> > <marcinx.smoczynski@intel.com>; Mariusz Drost
> > <mariuszx.drost@intel.com>
> > Subject: [dpdk-dev] [PATCH v1] net/tap: fix blocked rx packets error
> >
> > When OS sends more packets than are beaing read with a single
> s/ beaing/being

Thanks for that, will be corrected in the v2.

> 
> > 'rte_eth_rx_burst' call, rx packets are getting stucked in the tap pmd
> > and are unable to receive, because trigger_seen is getting updated and
> > consecutive calls are not getting any packets.
> >
> > Do not update trigger_seen unless less than a max number of packets
> > were received allowing next call to receive the rest.
> >
> > Fixes: a0d8e807d9 ("net/tap: add Rx trigger")
> > Cc: stable@dpdk.org
> >
> > Tested-by: Mariusz Drost <mariuszx.drost@intel.com>
> > Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
> > ---
> >  drivers/net/tap/rte_eth_tap.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/tap/rte_eth_tap.c
> > b/drivers/net/tap/rte_eth_tap.c index 64bd04911..60121ae56 100644
> > --- a/drivers/net/tap/rte_eth_tap.c
> > +++ b/drivers/net/tap/rte_eth_tap.c
> > @@ -353,8 +353,7 @@ pmd_rx_burst(void *queue, struct rte_mbuf
> **bufs,
> > uint16_t nb_pkts)
> >
> >       if (trigger == rxq->trigger_seen)
> >               return 0;
> > -     if (trigger)
> > -             rxq->trigger_seen = trigger;
> > +
> >       process_private = rte_eth_devices[rxq->in_port].process_private;
> >       rte_compiler_barrier();
> I see this compiler barrier was added together with the above "rxq-
> >trigger_seen = trigger", should it be removed or moved together
> downwards?

I think it could be removed, but it is best to ask author of the original code.
Adrien, what do you think about removing this barrier?
 

> 
> >       for (num_rx = 0; num_rx < nb_pkts; ) { @@ -433,6 +432,9 @@
> > pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> >       rxq->stats.ipackets += num_rx;
> >       rxq->stats.ibytes += num_rx_bytes;
> >
> > +     if (trigger && num_rx < nb_pkts)
> > +             rxq->trigger_seen = trigger;
> > +
> >       return num_rx;
> >  }
> >
> > --
> > 2.17.1
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
diff mbox series

Patch

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 64bd04911..60121ae56 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -353,8 +353,7 @@  pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 
 	if (trigger == rxq->trigger_seen)
 		return 0;
-	if (trigger)
-		rxq->trigger_seen = trigger;
+
 	process_private = rte_eth_devices[rxq->in_port].process_private;
 	rte_compiler_barrier();
 	for (num_rx = 0; num_rx < nb_pkts; ) {
@@ -433,6 +432,9 @@  pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 	rxq->stats.ipackets += num_rx;
 	rxq->stats.ibytes += num_rx_bytes;
 
+	if (trigger && num_rx < nb_pkts)
+		rxq->trigger_seen = trigger;
+
 	return num_rx;
 }