[v5] gro : packets not getting flushed in heavy-weight mode API
Checks
Commit Message
In heavy-weight mode GRO which is based on timer, the GRO packets
will not be flushed in spite of timer expiry if there is no packet
in the current poll. If timer mode GRO is enabled the
rte_gro_timeout_flush API should be invoked.
Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
---
v1:
Changes to make sure that the GRO flush API is invoked if there are no packets in
current poll and timer expiry.
v2:
Fix code organisation issue
v3:
Fix warnings
v4:
Fix error and warnings
v5:
Fix compilation issue when GRO is not defined
app/test-pmd/csumonly.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
Comments
On 1/18/2024 8:36 AM, Kumara Parameshwaran wrote:
> In heavy-weight mode GRO which is based on timer, the GRO packets
> will not be flushed in spite of timer expiry if there is no packet
> in the current poll. If timer mode GRO is enabled the
> rte_gro_timeout_flush API should be invoked.
>
Agree on the problem, need a way to flush existing packets in GRO
context when no more packet receiving.
> Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
> ---
> v1:
> Changes to make sure that the GRO flush API is invoked if there are no packets in
> current poll and timer expiry.
>
> v2:
> Fix code organisation issue
>
> v3:
> Fix warnings
>
> v4:
> Fix error and warnings
>
> v5:
> Fix compilation issue when GRO is not defined
>
> app/test-pmd/csumonly.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index c103e54111..6d9ce99500 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -863,16 +863,23 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>
> /* receive a burst of packet */
> nb_rx = common_fwd_stream_receive(fs, pkts_burst, nb_pkt_per_burst);
> +#ifndef RTE_LIB_GRO
> if (unlikely(nb_rx == 0))
> return false;
> -
> +#else
> + gro_enable = gro_ports[fs->rx_port].enable;
> + if (unlikely(nb_rx == 0)) {
> + if (gro_enable && (gro_flush_cycles != GRO_DEFAULT_FLUSH_CYCLES))
> + goto init;
>
Rest of the function expects 'nb_rx' non zero, so I am concerned about
unexpected side effects, like:
- GRO reassembles packets and flush, how reassembles behaves with zero
nb_rx?
- If there is no packet in GRO context, what happens to call with zero
nb_rx?
To address above issue, what about add 'rte_gro_get_pkt_count()' check
and only continue if it return not zero.
Also in below GRO block, call 'rte_gro_reassemble()' only when 'nb_rx'
is not zero.
> + else
> + return false;
>
'goto' can be prevented by changing the condition in if block.
> + }
> +init:
>
Label name 'init' is not a good name.
> +#endif
> rx_bad_ip_csum = 0;
> rx_bad_l4_csum = 0;
> rx_bad_outer_l4_csum = 0;
> rx_bad_outer_ip_csum = 0;
> -#ifdef RTE_LIB_GRO
> - gro_enable = gro_ports[fs->rx_port].enable;
> -#endif
>
> txp = &ports[fs->tx_port];
> tx_offloads = txp->dev_conf.txmode.offloads;
@@ -863,16 +863,23 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
/* receive a burst of packet */
nb_rx = common_fwd_stream_receive(fs, pkts_burst, nb_pkt_per_burst);
+#ifndef RTE_LIB_GRO
if (unlikely(nb_rx == 0))
return false;
-
+#else
+ gro_enable = gro_ports[fs->rx_port].enable;
+ if (unlikely(nb_rx == 0)) {
+ if (gro_enable && (gro_flush_cycles != GRO_DEFAULT_FLUSH_CYCLES))
+ goto init;
+ else
+ return false;
+ }
+init:
+#endif
rx_bad_ip_csum = 0;
rx_bad_l4_csum = 0;
rx_bad_outer_l4_csum = 0;
rx_bad_outer_ip_csum = 0;
-#ifdef RTE_LIB_GRO
- gro_enable = gro_ports[fs->rx_port].enable;
-#endif
txp = &ports[fs->tx_port];
tx_offloads = txp->dev_conf.txmode.offloads;