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; } -- 2.17.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
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.
> -----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.
When OS sends more packets than are being 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. v1 to v2 changes: - fix typo in commit description - remove unnecessary compiler barrier Marcin Smoczynski (1): net/tap: fix blocked rx packets error drivers/net/tap/rte_eth_tap.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.17.1
When OS sends more packets than are being 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. Remove unnecessary compiler barrier. Fixes: a0d8e807d9 ("net/tap: add Rx trigger") Cc: stable@dpdk.org Tested-by: Mariusz Drost <mariuszx.drost@intel.com> Tested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com> --- drivers/net/tap/rte_eth_tap.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c index 64bd04911..9c3adb832 100644 --- a/drivers/net/tap/rte_eth_tap.c +++ b/drivers/net/tap/rte_eth_tap.c @@ -353,10 +353,8 @@ 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; ) { struct rte_mbuf *mbuf = rxq->pool; struct rte_mbuf *seg = NULL; @@ -433,6 +431,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
> On Sep 23, 2019, at 8:22 AM, Smoczynski, MarcinX <marcinx.smoczynski@intel.com> wrote: > > When OS sends more packets than are being 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. > > Remove unnecessary compiler barrier. > > Fixes: a0d8e807d9 ("net/tap: add Rx trigger") > Cc: stable@dpdk.org > > Tested-by: Mariusz Drost <mariuszx.drost@intel.com> > Tested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com> > --- > drivers/net/tap/rte_eth_tap.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c > index 64bd04911..9c3adb832 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -353,10 +353,8 @@ 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; ) { > struct rte_mbuf *mbuf = rxq->pool; > struct rte_mbuf *seg = NULL; > @@ -433,6 +431,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; Looks reasonable to me. I was looking at the code for this patch and noticed what I believe is a bit odd. The line around 1352 does set req->trigger_seen = 1;, but the tap_trigger global variable is always set to tap_trigger = (tap_trigger + 1) | 0x80000000; in the signal handler. Just seems the line around 1352 should be set to at least 0x80000001 to begin with just to be constant. Not for this patch and maybe it does not matter in the long run. Reviewed-by: Keith Wiles <Keith.Wiles@intel.com> > } > > -- > 2.17.1 > Regards, Keith
On 9/23/2019 3:41 PM, Wiles, Keith wrote:
>
>
>> On Sep 23, 2019, at 8:22 AM, Smoczynski, MarcinX <marcinx.smoczynski@intel.com> wrote:
>>
>> When OS sends more packets than are being 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.
>>
>> Remove unnecessary compiler barrier.
>>
>> Fixes: a0d8e807d9 ("net/tap: add Rx trigger")
>> Cc: stable@dpdk.org
>>
>> Tested-by: Mariusz Drost <mariuszx.drost@intel.com>
>> Tested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
>> ---
>> drivers/net/tap/rte_eth_tap.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
>> index 64bd04911..9c3adb832 100644
>> --- a/drivers/net/tap/rte_eth_tap.c
>> +++ b/drivers/net/tap/rte_eth_tap.c
>> @@ -353,10 +353,8 @@ 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; ) {
>> struct rte_mbuf *mbuf = rxq->pool;
>> struct rte_mbuf *seg = NULL;
>> @@ -433,6 +431,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;
>
> Looks reasonable to me. I was looking at the code for this patch and noticed what I believe is a bit odd.
>
> The line around 1352 does set req->trigger_seen = 1;, but the tap_trigger global variable is always set to tap_trigger = (tap_trigger + 1) | 0x80000000; in the signal handler.
> Just seems the line around 1352 should be set to at least 0x80000001 to begin with just to be constant. Not for this patch and maybe it does not matter in the long run.
>
>
> Reviewed-by: Keith Wiles <Keith.Wiles@intel.com>
Applied to dpdk-next-net/master, thanks.