Re: [PATCH v2] app/testpmd: use Tx preparation in txonly engine

[Ferruh Yigit <ferruh.yigit@amd.com>]

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?