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

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Thursday, 8 February 2024 11.50
> 
> > 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.

I strongly disagree with that statement, Konstantin!
It is not documented anywhere that using TX offloads and/or multisegs requires calling rte_eth_tx_prepare() before rte_eth_tx_burst(). And none of the examples do it.

In my opinion:
If some driver has limitations for a feature, e.g. max 8 fragments, it should be documented for that driver, so the application developer can make the appropriate decisions when designing the application.
Furthermore, we have APIs for the drivers to expose to the applications what the driver supports, so the application can configure itself optimally at startup. Perhaps those APIs need to be expanded.
And if a feature limitation is common across the majority of drivers, that limitation should be mentioned in the documentation of the feature itself.

We don't want to check in the fast path what can be checked at startup or build time!

> If it still works for some cases, that's a lucky coincidence, but not
> the expected behavior.
> 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.
> Again, we can add manual check in testpmd tx-only code to decide do we
> need a TX prepare
> to be called or not.
> Konstantin