> From: Sunil Kumar Kori [mailto:sk...@marvell.com] > Sent: Monday, 16 June 2025 10.36 > > > > > 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.
I still like this patch, so I confirm my ACK: Acked-by: Morten Brørup <m...@smartsharesystems.com>
