* [dpdk-dev] Breakage in l3fwd example with new event main loop
@ 2020-05-21 23:09 Stephen Hemminger
0 siblings, 0 replies; only message in thread
From: Stephen Hemminger @ 2020-05-21 23:09 UTC (permalink / raw)
To: Pavan Nikhilesh, dev
The l3fwd implement to do events has lots of copy/paste code.
Much of this must be never tested because it has compile errors.
Example:
static __rte_always_inline uint16_t
lpm_process_event_pkt(const struct lcore_conf *lconf, struct rte_mbuf *mbuf)
{
mbuf->port = lpm_get_dst_port(lconf, mbuf, mbuf->port);
#if defined RTE_ARCH_X86 || defined RTE_MACHINE_CPUFLAG_NEON \
|| 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; <<<<<<<<< not in loop?
}
If the checks are enabled, the code doesn't compile because continue
is not in a loop.
Which leads to a number of observations:
- copy/paste is bad, see DNR principle. Better to make it an inline
- #ifdef are evil since no one ever tests the other half
- why did CI not catch this?
- do you ever build on other architectures?
Please fix!
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-05-21 23:09 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-21 23:09 [dpdk-dev] Breakage in l3fwd example with new event main loop Stephen Hemminger
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).