[PATCH v2] app/testpmd: expand noisy neighbour forward mode support

[Mike Pattrick]

On Wed, Feb 1, 2023 at 10:19 AM Singh, Aman Deep
<aman.deep.singh at intel.com> wrote:
>
> Hi Mike,
>
> Thanks a lot for the patch.
>
> On 1/26/2023 10:25 AM, Mike Pattrick wrote:
>
> Previously the noisy neighbour vnf simulation would only operate in io
> mode, forwarding packets as is. However, this limited the usefulness of
> noisy neighbour simulation.
>
> This feature has now been expanded into all forwarding modes except for
> ieee1588, where it isn't relevant; and iofwd, which would otherwise be
> duplicative of noisy mode.
>
> Well I would first like to know, why we need noisy neighbor for all modes
> IMHO, do we need to add code to each mode, if most users don't use it.
>
> Secondly, can't we achieve same behavior by running testpmd instances in
> parallel on same NUMA node. Where one testpmd is in noisy mode.

I don't think the dual testpmd solution is identical, one of the
motivations for this change is to actually run the other modes with
the characteristics of the noisy mode. If we ran noisy with another
mode, that other mode would experience cache and memory contention,
but wouldn't experience queuing; and the contention wouldn't be
directly correlated with the exact packets that it forwarded, but
instead with the packets that noisy was forwarding.

Would it be preferable if I changed how this worked to not impact the
other forward modes when noisy options are disabled? I could change
this to switch the value of packet_fwd when noisy options are set. I
could also just move the full implementation back into noisy_vnf.c and
add a new option to affect how it forwards.


Thank you,
Mike

>
> Signed-off-by: Mike Pattrick <mkp at redhat.com>
>
> ---
>
> <snip>