> > 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.
> [1]: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__inbox.dpdk.org_dev_581e7a5389f842a9824a365a46c470ad- > 40huawei.com_&d=DwIFAw&c=nKjWec2b6R0mOyPaz7xtfQ&r=dXeXaAMkP5COgn1zx > HMyaF1_d9IIuq6vHQO6NrIPjaE&m=kCcHSf697ZGAlmjtOXGJe9h7VNzQg7yxhU2aYRbf > - > 3fDNbnnKjbeZUqgMpvhL8Xe&s=eob_TZZsekAeDDGzD15QMOhhpbe7PQScJLLP6IMrqg > 4&e= >
