On 9/13/22 06:22, Ferruh Yigit wrote: > On 7/25/2022 5:08 AM, Chengwen Feng wrote: > > > I assume intention is to make this as transparent as possible to the > user, that is why you are using a wrapper that combines > `rte_eth_tx_prepare()` & `rte_eth_tx_burst()` APIs. But for other PMDs > `rte_eth_tx_burst()` is called explicitly by the application. > > Path is also adding two new bonding specific APIs to enable/disable Tx > prepare. > Instead if you leave calling `rte_eth_tx_prepare()` decision to user, > there will be no need for the enable/disable Tx prepare APIs and the > wrapper. > > The `tx_pkt_prepare()` implementation in bonding can do the mode check, > call Tx prepare for all slaves and apply failure recovery, as done in > this wrapper function, what do you think, will it work? >
If you leave calling tx_prepare to the user, you need to perform a hash calculation to determine an output device. Since the output devices might be different types, you really need to know which device's tx_prepare needs to be called. You potentially will calculate the packet hash twice. While you could be clever with storing the hash in the mbuf somewhere, that's likely more complicated.
