On Thu, Feb 8, 2024 at 6:15 AM Ferruh Yigit <ferruh.yi...@amd.com> 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
We don't need to have full-blown NEW need forwarding engine.
Just that, we need to select correct ".packet_fwd" based on the
offload requirements.
It is easy to avoid code duplication by following without performance
impact by moving the logic to compile time and use runtime to fix up
static inline
generic_tx_only_packet_forward(...., const unsigned flag)
{
#logic common for both packet forward
#if (flag & NEED_PREPARE)
prepare specific code
}
static
generic_tx_only_packet_forward_without_prepare()
{
generic_tx_only_packet_forward(..., 0);
}
static
generic_tx_only_packet_forward_with_prepare()
{
generic_tx_only_packet_forward(..., NEED_PREPARE);
}
Select the correct .packet_fwd in
runtime(generic_tx_only_packet_forward_without_prepare() vs
generic_tx_only_packet_forward_with_prepare())
> be handled in device level.
>
