> >>> @@ -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.
In theory, the same Tx function needs to be used for different queues.
Because some hardware configurations are not per-queue, like MTU.
> 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.
I wonder when 'txgbe_txq_vec_setup()' will fail. It should be when there is
a memory allocation error. Then the application will fail to initialize?
> 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.
Yes, other issues will be fixed in the next version.
I am sorry that I have been busy with other work these months. I will
send the next version in these two days.
