[PATCH v3 1/3] ethdev: enable direct rearm with separate API
Morten Brørup
mb at smartsharesystems.com
Mon Mar 6 14:26:22 CET 2023
> From: Ferruh Yigit [mailto:ferruh.yigit at amd.com]
> Sent: Monday, 6 March 2023 13.49
>
> On 1/4/2023 8:21 AM, Morten Brørup wrote:
> >> From: Feifei Wang [mailto:feifei.wang2 at arm.com]
> >> Sent: Wednesday, 4 January 2023 08.31
> >>
> >> Add 'tx_fill_sw_ring' and 'rx_flush_descriptor' API into direct rearm
> >> mode for separate Rx and Tx Operation. And this can support different
> >> multiple sources in direct rearm mode. For examples, Rx driver is
> >> ixgbe,
> >> and Tx driver is i40e.
> >>
> >> Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
> >> Suggested-by: Ruifeng Wang <ruifeng.wang at arm.com>
> >> Signed-off-by: Feifei Wang <feifei.wang2 at arm.com>
> >> Reviewed-by: Ruifeng Wang <ruifeng.wang at arm.com>
> >> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
> >> ---
> >
> > This feature looks very promising for performance. I am pleased to see
> progress on it.
> >
>
> Hi Morten,
>
> Yes it brings some performance, but not to generic use case, only to
> specific and constraint use case.
I got the impression that the supported use case is a prominent and important use case.
This is the primary argument for considering such a complex non-generic feature.
>
> And changes are relatively invasive comparing the usecase it supports,
> like it adds new two inline datapath functions and a new dev_ops.
>
> I am worried the unnecessary complexity and possible regressions in the
> fundamental and simple parts of the project, with a good intention to
> gain a few percentage performance in a specific usecase, can hurt the
> project.
>
>
> I can see this is compared to MBUF_FAST_FREE feature, but MBUF_FAST_FREE
> is just an offload benefiting from existing offload infrastructure,
> which requires very small update and logically change in application and
> simple to implement in the drivers. So, they are not same from
> complexity perspective.
>
> Briefly, I am not comfortable with this change, I would like to see an
> explicit approval and code review from techboard to proceed.
I agree that the complexity is very high, and thus requires extra consideration. Your suggested techboard review and approval process seems like a good solution.
And the performance benefit of direct rearm should be compared to the performance using the new zero-copy mempool API.
-Morten
More information about the dev
mailing list