On Sat, 28 Jun 2025 15:25:37 +0800
Feifei Wang <wff_li...@vip.163.com> wrote:
> +#define HINIC3_RX_EMPTY_THRESHOLD 3
> +u16
> +hinic3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, u16 nb_pkts)
> +{
> + struct hinic3_rxq *rxq = rx_queue;
> + struct hinic3_rx_info *rx_info = NULL;
> + volatile struct hinic3_rq_cqe *rx_cqe = NULL;
> + struct rte_mbuf *rxm = NULL;
> + u16 sw_ci, rx_buf_len, wqebb_cnt = 0, pkts = 0;
> + u32 status, pkt_len, vlan_len, offload_type, lro_num;
> + u64 rx_bytes = 0;
> + u32 hash_value;
> +
> +#ifdef HINIC3_XSTAT_PROF_RX
> + uint64_t t1 = rte_get_tsc_cycles();
> + uint64_t t2;
> +#endif
> + if (((rte_get_timer_cycles() - rxq->rxq_stats.tsc) <
> rxq->wait_time_cycle) &&
> + rxq->rxq_stats.empty >= HINIC3_RX_EMPTY_THRESHOLD)
> + goto out;
> +
NAK
Doing this kind of empty threshold on receive is non-standard.
Driver should not be doing it here.
Many applications do polling optimization in themselves in the polling loop.
This driver specific tweak would interfere with that.
