From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Jiawen Wu <jiawenwu@trustnetic.com>, dev@dpdk.org
Subject: Re: [PATCH 1/2] net/txgbe: add vectorized functions for Rx/Tx
Date: Thu, 21 Mar 2024 16:21:57 +0000 [thread overview]
Message-ID: <a15822cc-29a3-471a-aa02-30511c106fc3@amd.com> (raw)
In-Reply-To: <07f901da6ed4$a3914660$eab3d320$@trustnetic.com>
On 3/5/2024 8:10 AM, Jiawen Wu wrote:
> On Wed, Feb 7, 2024 11:13 AM, Ferruh.Yigit@amd.com wrote:
>> On 2/1/2024 3:00 AM, Jiawen Wu wrote:
>>> To optimize Rx/Tx burst process, add SSE/NEON vector instructions on
>>> x86/arm architecture.
>>>
>>
>> Do you have any performance improvement number with vector
>> implementation, if so can you put it into commit log for record?
>
> On our local x86 platforms, the performance was at full speed without
> using vector. So we don't have the performance improvement number
> with SSE yet. But I will add the test result for arm.
>
Ack
>>> @@ -2198,8 +2220,15 @@ txgbe_set_tx_function(struct rte_eth_dev *dev, struct txgbe_tx_queue *txq)
>>> #endif
>>> txq->tx_free_thresh >= RTE_PMD_TXGBE_TX_MAX_BURST) {
>>> PMD_INIT_LOG(DEBUG, "Using simple tx code path");
>>> - dev->tx_pkt_burst = txgbe_xmit_pkts_simple;
>>> dev->tx_pkt_prepare = NULL;
>>> + if (txq->tx_free_thresh <= RTE_TXGBE_TX_MAX_FREE_BUF_SZ &&
>>> + (rte_eal_process_type() != RTE_PROC_PRIMARY ||
>>>
>>
>> Why vector Tx enable only for secondary process?
>
> It is not only for secondary process. The constraint is
>
> (rte_eal_process_type() != RTE_PROC_PRIMARY || txgbe_txq_vec_setup(txq) == 0)
>
> This code references ixgbe, which explains:
> "When using multiple processes, the TX function used in all processes
> should be the same, otherwise the secondary processes cannot transmit
> more than tx-ring-size - 1 packets.
> To achieve this, we extract out the code to select the ixgbe TX function
> to be used into a separate function inside the ixgbe driver, and call
> that from a secondary process when it is attaching to an
> already-configured NIC."
>
Got it,
1- Is txgbe has the constraint that same Tx function should be used
separate queues?
Tx functions is all in SW, right? HW interface is same, so HW doesn't
know or care vector Tx or simple Tx is used.
As primary and secondary processes manage different queues, I don't know
why this constraint exists.
2. I see above logic prevents secondary to call 'txgbe_txq_vec_setup()'
again. Perhaps unlikely but technically, if 'txgbe_txq_vec_setup()'
fails for primary 'txgbe_xmit_pkts_simple' is set and for secondary
'txgbe_xmit_pkts_vec' is set, causing both primary and secondary have
different Tx functions, can you please check if this option is valid.
There are other comments not addressed, I assume they are accepted and
there will be a new version, but I want to highlight in case they are
missed.
next prev parent reply other threads:[~2024-03-21 16:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 3:00 [PATCH 0/2] Wangxun support vector Rx/Tx Jiawen Wu
2024-02-01 3:00 ` [PATCH 1/2] net/txgbe: add vectorized functions for Rx/Tx Jiawen Wu
2024-02-07 3:13 ` Ferruh Yigit
2024-03-05 8:10 ` Jiawen Wu
2024-03-21 16:21 ` Ferruh Yigit [this message]
2024-04-07 8:32 ` Jiawen Wu
2024-03-21 16:27 ` Ferruh Yigit
2024-03-21 17:55 ` Tyler Retzlaff
2024-02-01 3:00 ` [PATCH 2/2] net/ngbe: " Jiawen Wu
2024-02-06 1:50 ` [PATCH 0/2] Wangxun support vector Rx/Tx Jiawen Wu
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=a15822cc-29a3-471a-aa02-30511c106fc3@amd.com \
--to=ferruh.yigit@amd.com \
--cc=dev@dpdk.org \
--cc=jiawenwu@trustnetic.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).