[PATCH v2 2/2] ethdev: remove callback checks from fast path
Sunil Kumar Kori
skori at marvell.com
Tue Jun 10 07:11:57 CEST 2025
> > From: Sunil Kumar Kori <skori at 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.ananyev at 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=
>
More information about the dev
mailing list