[1/1] examples/l3fwd: fix scalar LPM compilation

Message ID 20220510115844.458009-1-kda@semihalf.com (mailing list archive)
State Superseded, archived
Delegated to: David Marchand
Headers
Series [1/1] examples/l3fwd: fix scalar LPM compilation |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-aarch64-unit-testing success Testing PASS
ci/iol-aarch64-compile-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/github-robot: build success github build: passed
ci/iol-intel-Performance success Performance Testing PASS

Commit Message

Stanislaw Kardach May 10, 2022, 11:58 a.m. UTC
  The lpm_process_event_pkt() can either process a packet using an
architecture specific (defined for X86/SSE, ARM/Neon and PPC64/Altivec)
path or a scalar one. The choice is however done using an ifdef
pre-processor macro. Because of that the scalar version was apparently
not widely excersized/compiled.
Due to some copy/paste errors, the scalar logic in
lpm_process_event_pkt() retained a "continue" statement where a BAD_PORT
should be returned after refactoring of the LPM logic in the l3fwd
example.

Fixes: 99fc91d18082 ("examples/l3fwd: add event lpm main loop")
Cc: pbhagavatula@marvell.com

Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
 examples/l3fwd/l3fwd_lpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

David Marchand May 11, 2022, 11:38 a.m. UTC | #1
Hello Stanislaw,

On Tue, May 10, 2022 at 1:59 PM Stanislaw Kardach <kda@semihalf.com> wrote:
>
> The lpm_process_event_pkt() can either process a packet using an
> architecture specific (defined for X86/SSE, ARM/Neon and PPC64/Altivec)
> path or a scalar one. The choice is however done using an ifdef
> pre-processor macro. Because of that the scalar version was apparently
> not widely excersized/compiled.
> Due to some copy/paste errors, the scalar logic in
> lpm_process_event_pkt() retained a "continue" statement where a BAD_PORT
> should be returned after refactoring of the LPM logic in the l3fwd
> example.
>
> Fixes: 99fc91d18082 ("examples/l3fwd: add event lpm main loop")
> Cc: pbhagavatula@marvell.com
>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> ---
>  examples/l3fwd/l3fwd_lpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
> index bec22c44cd..6e1defbf7f 100644
> --- a/examples/l3fwd/l3fwd_lpm.c
> +++ b/examples/l3fwd/l3fwd_lpm.c
> @@ -248,7 +248,7 @@ lpm_process_event_pkt(const struct lcore_conf *lconf, struct rte_mbuf *mbuf)
>                 if (is_valid_ipv4_pkt(ipv4_hdr, mbuf->pkt_len)
>                                 < 0) {
>                         mbuf->port = BAD_PORT;
> -                       continue;
> +                       return mbuf->port;
>                 }
>                 /* Update time to live and header checksum */
>                 --(ipv4_hdr->time_to_live);

Based on the vector specific implemtations of process_packet in this
example, this code could be replaced with a call to rfc1812_process().
Eth macs updates can be moved prior to rfc1812_process.

What do you think of (untested):

diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index bec22c44cd..c73cbda6b5 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -234,33 +234,18 @@ lpm_process_event_pkt(const struct lcore_conf
*lconf, struct rte_mbuf *mbuf)
        || defined RTE_ARCH_PPC_64
        process_packet(mbuf, &mbuf->port);
 #else
-
        struct rte_ether_hdr *eth_hdr = rte_pktmbuf_mtod(mbuf,
                        struct rte_ether_hdr *);
-#ifdef DO_RFC_1812_CHECKS
-       struct rte_ipv4_hdr *ipv4_hdr;
-       if (RTE_ETH_IS_IPV4_HDR(mbuf->packet_type)) {
-               /* Handle IPv4 headers.*/
-               ipv4_hdr = rte_pktmbuf_mtod_offset(mbuf,
-                               struct rte_ipv4_hdr *,
-                               sizeof(struct rte_ether_hdr));
-
-               if (is_valid_ipv4_pkt(ipv4_hdr, mbuf->pkt_len)
-                               < 0) {
-                       mbuf->port = BAD_PORT;
-                       continue;
-               }
-               /* Update time to live and header checksum */
-               --(ipv4_hdr->time_to_live);
-               ++(ipv4_hdr->hdr_checksum);
-       }
-#endif
+
        /* dst addr */
        *(uint64_t *)&eth_hdr->dst_addr = dest_eth_addr[mbuf->port];

        /* src addr */
        rte_ether_addr_copy(&ports_eth_addr[mbuf->port],
                        &eth_hdr->src_addr);
+
+       rfc1812_process((struct rte_ipv4_hdr *)(eth_hdr + 1), &mbuf->port,
+               mbuf->packet_type);
 #endif
        return mbuf->port;
 }
  
Stanislaw Kardach May 11, 2022, 2:18 p.m. UTC | #2
On Wed, May 11, 2022 at 1:39 PM David Marchand
<david.marchand@redhat.com> wrote:
<snip>
> Based on the vector specific implemtations of process_packet in this
> example, this code could be replaced with a call to rfc1812_process().
> Eth macs updates can be moved prior to rfc1812_process.
>
> What do you think of (untested):
That actually looks a lot better! Though it seems safer to use
rte_pktmbuf_mtod_offset() for getting the ipv4_hdr. I'll post V2 with
this update.
  

Patch

diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index bec22c44cd..6e1defbf7f 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -248,7 +248,7 @@  lpm_process_event_pkt(const struct lcore_conf *lconf, struct rte_mbuf *mbuf)
 		if (is_valid_ipv4_pkt(ipv4_hdr, mbuf->pkt_len)
 				< 0) {
 			mbuf->port = BAD_PORT;
-			continue;
+			return mbuf->port;
 		}
 		/* Update time to live and header checksum */
 		--(ipv4_hdr->time_to_live);