From: Feifei Wang <Feifei.Wang2@arm.com>
To: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
Konstantin Ananyev <konstantin.ananyev@huawei.com>,
Yuying Zhang <Yuying.Zhang@intel.com>,
Beilei Xing <beilei.xing@intel.com>,
Ruifeng Wang <Ruifeng.Wang@arm.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
nd <nd@arm.com>
Subject: RE: 回复: [PATCH v3 2/3] net/i40e: enable direct rearm with separate API
Date: Thu, 23 Mar 2023 10:49:38 +0000 [thread overview]
Message-ID: <AS8PR08MB77184739ABAC4CB78379952CC8879@AS8PR08MB7718.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <5ff6e7c0-e38f-cc8d-d08d-c612e5505184@yandex.ru>
> -----Original Message-----
> From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> Sent: Monday, March 20, 2023 12:11 AM
> To: Feifei Wang <Feifei.Wang2@arm.com>; Konstantin Ananyev
> <konstantin.ananyev@huawei.com>; Yuying Zhang
> <Yuying.Zhang@intel.com>; Beilei Xing <beilei.xing@intel.com>; Ruifeng
> Wang <Ruifeng.Wang@arm.com>
> Cc: dev@dpdk.org; nd <nd@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>
> Subject: Re: 回复: [PATCH v3 2/3] net/i40e: enable direct rearm with
> separate API
>
>
> >>>>>>> +int
> >>>>>>> +i40e_tx_fill_sw_ring(void *tx_queue,
> >>>>>>> + struct rte_eth_rxq_rearm_data *rxq_rearm_data) {
> >>>>>>> + struct i40e_tx_queue *txq = tx_queue;
> >>>>>>> + struct i40e_tx_entry *txep;
> >>>>>>> + void **rxep;
> >>>>>>> + struct rte_mbuf *m;
> >>>>>>> + int i, n;
> >>>>>>> + int nb_rearm = 0;
> >>>>>>> +
> >>>>>>> + if (*rxq_rearm_data->rearm_nb < txq->tx_rs_thresh ||
> >>>>>>> + txq->nb_tx_free > txq->tx_free_thresh)
> >>>>>>> + return 0;
> >>>>>>> +
> >>>>>>> + /* check DD bits on threshold descriptor */
> >>>>>>> + if ((txq->tx_ring[txq->tx_next_dd].cmd_type_offset_bsz &
> >>>>>>> +
> >> rte_cpu_to_le_64(I40E_TXD_QW1_DTYPE_MASK)) !=
> >>>>>>> +
> >>>>>> rte_cpu_to_le_64(I40E_TX_DESC_DTYPE_DESC_DONE))
> >>>>>>> + return 0;
> >>>>>>> +
> >>>>>>> + n = txq->tx_rs_thresh;
> >>>>>>> +
> >>>>>>> + /* first buffer to free from S/W ring is at index
> >>>>>>> + * tx_next_dd - (tx_rs_thresh-1)
> >>>>>>> + */
> >>>>>>> + txep = &txq->sw_ring[txq->tx_next_dd - (n - 1)];
> >>>>>>> + rxep = rxq_rearm_data->rx_sw_ring;
> >>>>>>> + rxep += *rxq_rearm_data->rearm_start;
> >>>>>>> +
> >>>>>>> + if (txq->offloads &
> >> RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE) {
> >>>>>>> + /* directly put mbufs from Tx to Rx */
> >>>>>>> + for (i = 0; i < n; i++, rxep++, txep++)
> >>>>>>> + *rxep = txep[0].mbuf;
> >>>>>>> + } else {
> >>>>>>> + for (i = 0; i < n; i++, rxep++) {
> >>>>>>> + m = rte_pktmbuf_prefree_seg(txep[i].mbuf);
> >>>>
> >>>> One thing I forgot to ask:
> >>>> What would happen if this mbuf belongs to different mempool (not
> >>>> one that we specify at rx_queue_setup())?
> >>>> Do we need to check it here?
> >>>> Or would it be upper layer constraint?
> >>>> Or...?
> >>>>
> >>>
> >>> First, 'different mempool' is valid for no FAST_FREE path in
> tx_free_buffers.
> >>>
> >>> If buffers belong to different mempool, we can have an example here:
> >>> Buffer 1 from mempool 1, its recycle path is:
> >>> --------------------------------------------------------------------
> >>> --
> >>> ------------------- 1. queue_setup: rearm from mempool 1 into Rx
> >>> sw-ring 2. rte_eth_Rx_burst: used by user app (Rx) 3.
> >>> rte_eth_Tx_burst: mount on Tx sw-ring 4. rte_eth_direct_rearm: free
> >>> into Rx sw-ring:
> >>> or
> >>> tx_free_buffers: free into mempool 1 (no fast_free path)
> >>> --------------------------------------------------------------------
> >>> --
> >>> -------------------
> >>>
> >>> Buffer 2 from mempool 2, its recycle path is:
> >>> --------------------------------------------------------------------
> >>> --
> >>> ------------------- 1. queue_setup: rearm from mempool 2 into Rx
> >>> sw-ring 2. rte_eth_Rx_burst: used by user app (Rx) 3.
> >>> rte_eth_Tx_burst: mount on Tx sw-ring 4. rte_eth_direct_rearm: free
> >>> into Rx sw-ring
> >>> or
> >>> tx_free_buffers: free into mempool 2 (no fast_free_path)
> >>> --------------------------------------------------------------------
> >>> --
> >>> -------------------
> >>>
> >>> Thus, buffers from Tx different mempools are the same for Rx. The
> >>> difference point is that they will be freed into different mempool
> >>> if the
> >> thread uses generic free buffers.
> >>> I think this cannot affect direct-rearm mode, and we do not need to
> >>> check
> >> this.
> >>
> >> I understand that it should work even with multiple mempools.
> >> What I am trying to say - user may not want to use mbufs from
> >> particular mempool for RX (while it is still ok to use it for TX).
> >> Let say user can have a separate mempool with small data-buffers
> >> (less then normal MTU) to send some 'special' paclets, or even use
> >> this memppol with small buffers for zero-copy updating of packet L2/L3
> headers, etc.
> >> Or it could be some 'special' user provided mempool.
> >> That's why I wonder should we allow only mbufs from mempool that is
> >> assigned to that RX queue.
> >
> > Sorry for my misleading. If I understand correctly this time, you
> > means a special mempool. Maybe its buffer size is very small and this Tx
> buffer is generated from control plane.
> >
> > However, if we recycle this Tx buffer into Rx buffer ring, there maybe
> > some error due to its size is so small.
> >
> > Thus we can only allow general buffers which is valid for Rx buffer
> > ring. Furthermore, this should be user's responsibility to ensure the
> > Tx recycling buffers should be valid. If we check this in the data plane, it will
> cost a lot of CPU cycles. At last, what we can do is to add constraint in the
> notes to remind users.
>
> As I thought: in theory we can add 'struct rte_mempool *mp'
> into rte_eth_rxq_rearm_data.
> And then:
> if (mbuf->pool == rxq_rearm_data->mp)
> /* put mbuf into rearm buffer */
> else
> /* free mbuf */
> For the 'proper' config (when txq contains mbufs from expected mempool)
> the overhead will be minimal.
> In other case it might be higher, but still would work and no need for extra
> limitations.
It's a good idea. And try to test performance with this change, there is currently
no performance degradation. Thus, I add this check in the latest version.
>
>
> >>
> >>>
> >>>>>>> + if (m != NULL) {
> >>>>>>> + *rxep = m;
> >>>>>>> + nb_rearm++;
> >>>>>>> + }
> >>>>>>> + }
> >>>>>>> + n = nb_rearm;
> >>>>>>> + }
> >>>>>>> +
> >>>>>>> + /* update counters for Tx */
> >>>>>>> + txq->nb_tx_free = (uint16_t)(txq->nb_tx_free + txq-
> >>> tx_rs_thresh);
> >>>>>>> + txq->tx_next_dd = (uint16_t)(txq->tx_next_dd + txq-
> >>> tx_rs_thresh);
> >>>>>>> + if (txq->tx_next_dd >= txq->nb_tx_desc)
> >>>>>>> + txq->tx_next_dd = (uint16_t)(txq->tx_rs_thresh - 1);
> >>>>>>> +
> >>>>>>> + return n;
> >>>>>>> +}
> >>>>>>> +
next prev parent reply other threads:[~2023-03-23 10:49 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 8:16 [PATCH v1 0/5] Direct re-arming of buffers on receive side Feifei Wang
2022-04-20 8:16 ` [PATCH v1 1/5] net/i40e: remove redundant Dtype initialization Feifei Wang
2022-04-20 8:16 ` [PATCH v1 2/5] net/i40e: enable direct rearm mode Feifei Wang
2022-05-11 22:28 ` Konstantin Ananyev
2022-04-20 8:16 ` [PATCH v1 3/5] ethdev: add API for " Feifei Wang
2022-04-20 9:59 ` Morten Brørup
2022-04-29 2:42 ` 回复: " Feifei Wang
2022-04-20 10:41 ` Andrew Rybchenko
2022-04-29 6:28 ` 回复: " Feifei Wang
2022-05-10 22:49 ` Honnappa Nagarahalli
2022-06-03 10:19 ` Andrew Rybchenko
2022-04-20 10:50 ` Jerin Jacob
2022-05-02 3:09 ` 回复: " Feifei Wang
2022-04-21 14:57 ` Stephen Hemminger
2022-04-29 6:35 ` 回复: " Feifei Wang
2022-04-20 8:16 ` [PATCH v1 4/5] net/i40e: add direct rearm mode internal API Feifei Wang
2022-05-11 22:31 ` Konstantin Ananyev
2022-04-20 8:16 ` [PATCH v1 5/5] examples/l3fwd: enable direct rearm mode Feifei Wang
2022-04-20 10:10 ` Morten Brørup
2022-04-21 2:35 ` Honnappa Nagarahalli
2022-04-21 6:40 ` Morten Brørup
2022-05-10 22:01 ` Honnappa Nagarahalli
2022-05-11 7:17 ` Morten Brørup
2022-05-11 22:33 ` Konstantin Ananyev
2022-05-27 11:28 ` Konstantin Ananyev
2022-05-31 17:14 ` Honnappa Nagarahalli
2022-06-03 10:32 ` Andrew Rybchenko
2022-06-06 11:27 ` Konstantin Ananyev
2022-06-29 21:25 ` Honnappa Nagarahalli
2022-05-11 23:00 ` [PATCH v1 0/5] Direct re-arming of buffers on receive side Konstantin Ananyev
[not found] ` <20220516061012.618787-1-feifei.wang2@arm.com>
2022-05-24 1:25 ` Konstantin Ananyev
2022-05-24 12:40 ` Morten Brørup
2022-05-24 20:14 ` Honnappa Nagarahalli
2022-05-28 12:22 ` Konstantin Ananyev
2022-06-01 1:00 ` Honnappa Nagarahalli
2022-06-03 23:32 ` Konstantin Ananyev
2022-06-04 8:07 ` Morten Brørup
2022-06-29 21:58 ` Honnappa Nagarahalli
2022-06-30 15:21 ` Morten Brørup
2022-07-01 19:30 ` Honnappa Nagarahalli
2022-07-01 20:28 ` Morten Brørup
2022-06-13 5:55 ` 回复: " Feifei Wang
2023-01-04 7:30 ` [PATCH v3 0/3] " Feifei Wang
2023-01-04 7:30 ` [PATCH v3 1/3] ethdev: enable direct rearm with separate API Feifei Wang
2023-01-04 8:21 ` Morten Brørup
2023-01-04 8:51 ` 回复: " Feifei Wang
2023-01-04 10:11 ` Morten Brørup
2023-02-24 8:55 ` 回复: " Feifei Wang
2023-03-06 12:49 ` Ferruh Yigit
2023-03-06 13:26 ` Morten Brørup
2023-03-06 14:53 ` 回复: " Feifei Wang
2023-03-06 15:02 ` Ferruh Yigit
2023-03-07 6:12 ` Honnappa Nagarahalli
2023-03-07 10:52 ` Konstantin Ananyev
2023-03-07 20:41 ` Ferruh Yigit
2023-03-22 14:43 ` Honnappa Nagarahalli
2023-02-02 14:33 ` Konstantin Ananyev
2023-02-24 9:45 ` 回复: " Feifei Wang
2023-02-27 19:31 ` Konstantin Ananyev
2023-02-28 2:16 ` 回复: " Feifei Wang
2023-02-28 8:09 ` Morten Brørup
2023-03-01 7:34 ` 回复: " Feifei Wang
2023-01-04 7:30 ` [PATCH v3 2/3] net/i40e: " Feifei Wang
2023-02-02 14:37 ` Konstantin Ananyev
2023-02-24 9:50 ` 回复: " Feifei Wang
2023-02-27 19:35 ` Konstantin Ananyev
2023-02-28 2:15 ` 回复: " Feifei Wang
2023-03-07 11:01 ` Konstantin Ananyev
2023-03-14 6:07 ` 回复: " Feifei Wang
2023-03-19 16:11 ` Konstantin Ananyev
2023-03-23 10:49 ` Feifei Wang [this message]
2023-01-04 7:30 ` [PATCH v3 3/3] net/ixgbe: " Feifei Wang
2023-01-31 6:13 ` 回复: [PATCH v3 0/3] Direct re-arming of buffers on receive side Feifei Wang
2023-02-01 1:10 ` Konstantin Ananyev
2023-02-01 2:24 ` 回复: " Feifei Wang
2023-03-22 12:56 ` Morten Brørup
2023-03-22 13:41 ` Honnappa Nagarahalli
2023-03-22 14:04 ` Morten Brørup
2023-08-02 7:38 ` [PATCH v8 0/4] Recycle mbufs from Tx queue into Rx queue Feifei Wang
2023-08-02 7:38 ` [PATCH v8 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2023-08-02 7:38 ` [PATCH v8 2/4] net/i40e: implement " Feifei Wang
2023-08-02 7:38 ` [PATCH v8 3/4] net/ixgbe: " Feifei Wang
2023-08-02 7:38 ` [PATCH v8 4/4] app/testpmd: add recycle mbufs engine Feifei Wang
2023-08-02 8:08 ` [PATCH v9 0/4] Recycle mbufs from Tx queue into Rx queue Feifei Wang
2023-08-02 8:08 ` [PATCH v9 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2023-08-02 8:08 ` [PATCH v9 2/4] net/i40e: implement " Feifei Wang
2023-08-02 8:08 ` [PATCH v9 3/4] net/ixgbe: " Feifei Wang
2023-08-02 8:08 ` [PATCH v9 4/4] app/testpmd: add recycle mbufs engine Feifei Wang
2023-08-04 9:24 ` [PATCH v10 0/4] Recycle mbufs from Tx queue into Rx queue Feifei Wang
2023-08-04 9:24 ` [PATCH v10 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2023-08-04 9:24 ` [PATCH v10 2/4] net/i40e: implement " Feifei Wang
2023-08-04 9:24 ` [PATCH v10 3/4] net/ixgbe: " Feifei Wang
2023-08-04 9:24 ` [PATCH v10 4/4] app/testpmd: add recycle mbufs engine Feifei Wang
2023-08-22 7:27 ` [PATCH v11 0/4] Recycle mbufs from Tx queue into Rx queue Feifei Wang
2023-08-22 7:27 ` [PATCH v11 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2023-08-22 14:02 ` Stephen Hemminger
2023-08-24 3:16 ` Feifei Wang
2023-08-22 23:33 ` Konstantin Ananyev
2023-08-24 3:38 ` Feifei Wang
2023-08-22 7:27 ` [PATCH v11 2/4] net/i40e: implement " Feifei Wang
2023-08-22 23:43 ` Konstantin Ananyev
2023-08-24 6:10 ` Feifei Wang
2023-08-31 17:24 ` Konstantin Ananyev
2023-08-31 23:49 ` Konstantin Ananyev
2023-09-01 12:22 ` Feifei Wang
2023-09-01 14:22 ` Konstantin Ananyev
2023-09-04 6:59 ` Feifei Wang
2023-09-04 7:49 ` Konstantin Ananyev
2023-09-04 9:24 ` Feifei Wang
2023-09-04 10:21 ` Konstantin Ananyev
2023-09-05 3:11 ` Feifei Wang
2023-09-22 14:58 ` Feifei Wang
2023-09-22 15:46 ` Feifei Wang
2023-09-22 16:40 ` Konstantin Ananyev
2023-09-23 5:52 ` Feifei Wang
2023-09-23 20:40 ` Konstantin Ananyev
2023-09-25 3:26 ` Feifei Wang
2023-08-22 7:27 ` [PATCH v11 3/4] net/ixgbe: " Feifei Wang
2023-08-22 7:27 ` [PATCH v11 4/4] app/testpmd: add recycle mbufs engine Feifei Wang
2023-08-22 7:33 ` [PATCH v11 0/4] Recycle mbufs from Tx queue into Rx queue Feifei Wang
2023-08-22 13:59 ` Stephen Hemminger
2023-08-24 3:11 ` Feifei Wang
2023-08-24 7:36 ` [PATCH v12 " Feifei Wang
2023-08-24 7:36 ` [PATCH v12 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2023-08-31 9:16 ` Feifei Wang
2023-09-20 13:10 ` Ferruh Yigit
2023-08-24 7:36 ` [PATCH v12 2/4] net/i40e: implement " Feifei Wang
2023-08-24 7:36 ` [PATCH v12 3/4] net/ixgbe: " Feifei Wang
2023-08-24 7:36 ` [PATCH v12 4/4] app/testpmd: add recycle mbufs engine Feifei Wang
2023-09-20 13:11 ` Ferruh Yigit
2023-09-20 13:12 ` [PATCH v12 0/4] Recycle mbufs from Tx queue into Rx queue Ferruh Yigit
2023-09-22 15:30 ` Ferruh Yigit
2023-09-25 3:19 ` [PATCH v13 " Feifei Wang
2023-09-25 3:19 ` [PATCH v13 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2023-09-25 4:40 ` Ajit Khaparde
2023-09-25 3:19 ` [PATCH v13 2/4] net/i40e: implement " Feifei Wang
2023-09-26 8:26 ` Ferruh Yigit
2023-09-26 8:56 ` Konstantin Ananyev
2023-09-26 13:34 ` Konstantin Ananyev
2023-09-25 3:19 ` [PATCH v13 3/4] net/ixgbe: " Feifei Wang
2023-09-26 13:30 ` Konstantin Ananyev
2023-09-25 3:19 ` [PATCH v13 4/4] app/testpmd: add recycle mbufs engine Feifei Wang
2023-09-26 13:30 ` Konstantin Ananyev
2023-09-26 16:38 ` Ajit Khaparde
2023-09-27 17:24 ` [PATCH v13 0/4] Recycle mbufs from Tx queue into Rx queue Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AS8PR08MB77184739ABAC4CB78379952CC8879@AS8PR08MB7718.eurprd08.prod.outlook.com \
--to=feifei.wang2@arm.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=Yuying.Zhang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).