Sorry for my delayed reply.
> -----邮件原件-----
> 发件人: Morten Brørup <m...@smartsharesystems.com>
> 发送时间: Wednesday, January 4, 2023 6:11 PM
> 收件人: Feifei Wang <feifei.wa...@arm.com>; tho...@monjalon.net;
> Ferruh Yigit <ferruh.yi...@amd.com>; Andrew Rybchenko
> <andrew.rybche...@oktetlabs.ru>
> 抄送: dev@dpdk.org; konstantin.v.anan...@yandex.ru; nd <n...@arm.com>;
> Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; Ruifeng Wang
> <ruifeng.w...@arm.com>; nd <n...@arm.com>
> 主题: RE: [PATCH v3 1/3] ethdev: enable direct rearm with separate API
>
> > From: Feifei Wang [mailto:feifei.wa...@arm.com]
> > Sent: Wednesday, 4 January 2023 09.51
> >
> > Hi, Morten
> >
> > > 发件人: Morten Brørup <m...@smartsharesystems.com>
> > > 发送时间: Wednesday, January 4, 2023 4:22 PM
> > >
> > > > From: Feifei Wang [mailto:feifei.wa...@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.nagaraha...@arm.com>
> > > > Suggested-by: Ruifeng Wang <ruifeng.w...@arm.com>
> > > > Signed-off-by: Feifei Wang <feifei.wa...@arm.com>
> > > > Reviewed-by: Ruifeng Wang <ruifeng.w...@arm.com>
> > > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
> > > > ---
> > >
> > > This feature looks very promising for performance. I am pleased to
> > see
> > > progress on it.
> > >
> > Thanks very much for your reviewing.
> >
> > > Please confirm that the fast path functions are still thread safe,
> > i.e. one EAL
> > > thread may be calling rte_eth_rx_burst() while another EAL thread is
> > calling
> > > rte_eth_tx_burst().
> > >
> > For the multiple threads safe, like we say in cover letter, current
> > direct-rearm support Rx and Tx in the same thread. If we consider
> > multiple threads like 'pipeline model', there need to add 'lock' in
> > the data path which can decrease the performance.
> > Thus, the first step we do is try to enable direct-rearm in the single
> > thread, and then we will consider to enable direct rearm in multiple
> > threads and improve the performance.
>
> OK, doing it in steps is a good idea for a feature like this - makes it
> easier to
> understand and review.
>
> When proceeding to add support for the "pipeline model", perhaps the
> lockless principles from the rte_ring can be used in this feature too.
>
> From a high level perspective, I'm somewhat worried that releasing a "work-
> in-progress" version of this feature in some DPDK version will cause API/ABI
> breakage discussions when progressing to the next steps of the
> implementation to make the feature more complete. Not only support for
> thread safety across simultaneous RX and TX, but also support for multiple
> mbuf pools per RX queue [1]. Marking the functions experimental should
> alleviate such discussions, but there is a risk of pushback to not break the
> API/ABI anyway.
>
> [1]:
> https://elixir.bootlin.com/dpdk/v22.11.1/source/lib/ethdev/rte_ethdev.h#L1
> 105
>
[Feifei] I think the subsequent upgrade does not significantly damage the
stability
of the API we currently define.
For thread safety across simultaneous RX and TX, in the future, the lockless
operation
change will happen in the pmd layer, such as CAS load/store for rxq queue index
of pmd.
Thus, this can not affect the stability of the upper API.
For multiple mbuf pools per RX queue, direct-rearm just put Tx buffers into Rx
buffers, and
it do not care which mempool the buffer coming from.
From different mempool buffers eventually freed into their respective sources
in the
no FAST_FREE path.
I think this is a mistake in cover letter. Previous direct-rearm can just
support FAST_FREE
so it constraint that buffer should be from the same mempool. Now, the latest
version can
support no_FAST_FREE path, but we forget to make change in cover letter.
> [...]
>
> > > > --- a/lib/ethdev/ethdev_driver.h
> > > > +++ b/lib/ethdev/ethdev_driver.h
> > > > @@ -59,6 +59,10 @@ struct rte_eth_dev {
> > > > eth_rx_descriptor_status_t rx_descriptor_status;
> > > > /** Check the status of a Tx descriptor */
> > > > eth_tx_descriptor_status_t tx_descriptor_status;
> > > > + /** Fill Rx sw-ring with Tx buffers in direct rearm mode */
> > > > + eth_tx_fill_sw_ring_t tx_fill_sw_ring;
> > >
> > > What is "Rx sw-ring"? Please confirm that this is not an Intel PMD
> > specific
> > > term and/or implementation detail, e.g. by providing a conceptual
> > > implementation for a non-Intel PMD, e.g. mlx5.
> > Rx sw_ring is used to store mbufs in intel PMD. This is the same as
> > 'rxq->elts'
> > in mlx5.
>
> Sounds good.
>
> Then all we need is consensus on a generic name for this, unless "Rx sw-ring"
> already is the generic name. (I'm not a PMD developer, so I might be
> completely off track here.) Naming is often debatable, so I'll stop talking
> about it now - I only wanted to highlight that we should avoid vendor-
> specific terms in public APIs intended to be implemented by multiple vendors.
> On the other hand... if no other vendors raise their voices before merging
> into the DPDK main repository, they forfeit their right to complain about it.
> ;-)
>
> > Agree with that we need to providing a conceptual implementation for
> > all PMDs.
>
> My main point is that we should ensure that the feature is not too tightly
> coupled with the way Intel PMDs implement mbuf handling. Providing a
> conceptual implementation for a non-Intel PMD is one way of checking this.
>
> The actual implementation in other PMDs could be left up to the various NIC
> vendors.
Yes. And we will rename our API to make it suitable for all vendors:
rte_eth_direct_rearm -> rte_eth_buf_cycle (upper API for direct rearm)
rte_eth_tx_fill_sw_ring -> rte_eth_tx_buf_stash (Tx queue fill Rx ring
buffer )
rte_eth_rx_flush_descriptor -> rte_eth_rx_descriptors_refill (Rx queue flush
its descriptors)
rte_eth_rxq_rearm_data {
void *rx_sw_ring;
uint16_t *rearm_start;
uint16_t *rearm_nb;
}
->
struct *rxq_recycle_info {
rte_mbuf **buf_ring;
uint16_t *offset = (uint16 *)(&rq-<ci);
uint16_t *end;
uint16_t ring_size;
}
