We are seeing issues with the DPDK 18.11 ENA PMD incrementing rx_errors stat on
good packets (checksum later validated by software). We’ve tried several
versions from DPDK 18.11 stable, including 18.11.9 and 18.11.10. Looking
through ENA PMD commits, I see there have been a number of rx stats
improvements. Some but not all have been back ported into DPDK 18.11 stable,
some of those presumably because they depend on updates to the base HW/HAL
layer. For example, in the latest ENA PMD driver, PKT_RX_L4_CKSUM_BAD can
only be set if the base layer has set l4_csum_checked in the RX context, a
feature that is not available in the DPDK 18.11 ENA base driver.
Is there a way to avoid incorrectly updating ierrors in DPDK 18.11 that does
not require upgrading the base HW/HAL? For example, if an application does not
enable IPV4, UDP or TCP RX checksum offloads, would l3_csum_err or l4_csum_err
ever be valid? If not, then would it be valid to pass ena_rx_mbuf_prepare() a
pointer to the adapter and check for l3/l4 checksum errors only if any of
DEV_RX_OFFLOAD_*CKSUM are set in
adapter->rte_eth_dev_data->dev_conf.rxmode.offloads? From DPDK 18.11.10, if RX
checksum offloads are not enabled, skip the highlighted code:
static inline void ena_rx_mbuf_prepare(struct rte_mbuf *mbuf,
struct
ena_com_rx_ctx *ena_rx_ctx)
{
uint64_t ol_flags = 0;
uint32_t packet_type = 0;
if (ena_rx_ctx->l4_proto == ENA_ETH_IO_L4_PROTO_TCP)
packet_type |= RTE_PTYPE_L4_TCP;
else if (ena_rx_ctx->l4_proto == ENA_ETH_IO_L4_PROTO_UDP)
packet_type |= RTE_PTYPE_L4_UDP;
if (ena_rx_ctx->l3_proto == ENA_ETH_IO_L3_PROTO_IPV4)
packet_type |= RTE_PTYPE_L3_IPV4;
else if (ena_rx_ctx->l3_proto == ENA_ETH_IO_L3_PROTO_IPV6)
packet_type |= RTE_PTYPE_L3_IPV6;
if (unlikely(ena_rx_ctx->l4_csum_err))
ol_flags |= PKT_RX_L4_CKSUM_BAD;
if (unlikely(ena_rx_ctx->l3_csum_err))
ol_flags |= PKT_RX_IP_CKSUM_BAD;
mbuf->ol_flags = ol_flags;
mbuf->packet_type = packet_type;
}
While reviewing the code, I also noticed that at the top of the tree, ierrors
are incremented in the transmit path:
static int ena_check_and_linearize_mbuf(struct ena_ring *tx_ring,
struct rte_mbuf *mbuf)
{
struct ena_com_dev *ena_dev;
int num_segments, header_len, rc;
--- snip ---
rc = rte_pktmbuf_linearize(mbuf);
if (unlikely(rc)) {
PMD_DRV_LOG(WARNING, "Mbuf linearize failed\n");
rte_atomic64_inc(&tx_ring->adapter->drv_stats->ierrors);
++tx_ring->tx_stats.linearize_failed;
return rc;
}
return rc;
}
This was introduced by 7830e905b7 net/ena: expose extended stats.
Shouldn’t oerrors be incremented in this case?
Thanks in advance for your help.
Regards,
Roger Melton
