On 2/8/2024 10:50 AM, Konstantin Ananyev wrote: > > >> On 1/11/2024 5:25 AM, Kaiwen Deng wrote: >>> Txonly forwarding engine does not call the Tx preparation API >>> before transmitting packets. This may cause some problems. >>> >>> TSO breaks when MSS spans more than 8 data fragments. Those >>> packets will be dropped by Tx preparation API, but it will cause >>> MDD event if txonly forwarding engine does not call the Tx preparation >>> API before transmitting packets. >>> >> >> txonly is used commonly, adding Tx prepare for a specific case may >> impact performance for users. >> >> What happens when driver throws MDD (Malicious Driver Detection) event, >> can't it be ignored? As you are already OK to drop the packet, can >> device be configured to drop these packages? >> >> >> Or as Jerin suggested adding a new forwarding engine is a solution, but >> that will create code duplication, I prefer to not have it if this can >> be handled in device level. > > Actually I am agree with the author of the patch - when TX offloads and/or > multisegs are enabled, > user supposed to invoke eth_tx_prepare(). > Not doing that seems like a bug to me. > If it still works for some cases, that's a lucky coincidence, but not the > expected behavior. >
fair enough > About performance - first we can check is that really a drop. > Also as I remember most drivers set it to non-NULL value, only when some TX > offloads were > enabled by the user on that port, so hopefully for simple case (one segment, > no tx offloads) it > should be negligible. > +1 to measure the impact, that helps to decide > Again, we can add manual check in testpmd tx-only code to decide do we need a > TX prepare > to be called or not. > What is the condition to call Tx prepare, is it only required when Tx offload are enabled? @Kaiwen can you please give some details on the problematic case, "MSS spans more than 8 data fragments", and how to produce it?
