> > > From: Sunil Kumar Kori <sk...@marvell.com> > > > Sent: Monday, 12 May 2025 17.07 > > > > > > rte_eth_fp_ops contains ops for fast path APIs. Each API validates > > > availability of callback and then invoke it. > > > These checks impact data path performace. > > > > Picking up the discussion from another thread [1]: > > > > > From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com] > > > Sent: Wednesday, 28 May 2025 11.14 > > > > > > So what we are saving with that patch: one cmp and one un-taken branch: > > > @@ -6399,8 +6399,6 @@ rte_eth_rx_queue_count(uint16_t port_id, > > > uint16_t > > > queue_id) > > > return -EINVAL; > > > #endif > > > > > > - if (p->rx_queue_count == NULL) > > > - return -ENOTSUP; > > > return p->rx_queue_count(qd); > > > } > > > > These are inline functions, so we also save some code space, > > instruction cache, and possibly an entry in the branch predictor - > > everywhere these functions are instantiated by the compiler. > > > > > > > > I wonder is how realistic (and measurable) is the gain? > > > > The performance optimization is mainly targeting the mbuf recycle > > operations, i.e. the hot fast path, where every cycle counts. > > And while optimizing those, the other ethdev fast path callbacks are > > also optimized. > > > > Yes, although we all agree that there is no downside to this > > optimization, it would be nice to see some performance numbers. > > > Sure, I will get performance numbers for Marvell platform and will share. >
Hi Morten, I got performance numbers on multiple Marvell's platforms and observed gain around 0.1% (~20K pps) with this patch. Other than this, there are other fast path callbacks (rx_pkt_burst and tx_pkt_burst) which avoid this check. IMO, this patch has no negative impact and slight improvement & cleanup the fast path. Please suggest.
