[PATCH v14 0/4] net/zxdh: optimize Rx/Tx path performance

[Stephen Hemminger]

On Thu,  3 Sep 2026 19:32:15 +0800
Junlong Wang <wang.junlong1 at zte.com.cn> wrote:

> v14:
>   - All Warnings AI review issues have been modified.
>   - Some info issues have been fixed, but the remaining
>     info issues cannot be fixed for various reasons.

Applied to next-net, with the release notes indentation fixed.

A few informational items from review that do not block this series;
they can be picked up in a follow-up if you want:

- zxdh_dequeue_burst_rx_packed() and zxdh_queue_rxvq_flush() index
  vq_descx[] with a device-written descriptor id and never check it
  against vq_nentries.  Patch 4 adds exactly that guard on the Tx
  side, so the two paths are now asymmetric.  Pre-existing, so a
  separate hardening patch is the right place for it.

- zxdh_refill_desc_unwrap() is a near-copy of
  zxdh_enqueue_recv_refill_packed(), which after patch 3 is only
  reached from zxdh_dev_rx_queue_setup_finish().  The setup path is
  not performance sensitive and could use the new helper, letting
  the old one go away.

- zxdh_queue_notify() is called whenever vq_free_cnt > 0, including
  when rte_pktmbuf_alloc_bulk() inside zxdh_refill_que_descs()
  failed and no descriptor was made available.  Returning the number
  refilled and notifying only on a non-zero result would drop an
  MMIO write on the mempool-exhausted path.

- Split-ring leftovers survive the cleanup: vq_desc_head_idx and
  vq_desc_tail_idx are written and never read, and struct
  zxdh_vq_desc_extra's "next" is written by
  zxdh_vring_desc_init_packed() and never read.  Dropping "next"
  would reduce vq_descx[] to a single pointer per entry.