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

["Singh, Aman Deep" <aman.deep.singh@intel.com>]

On 2/2/2023 12:33 AM, Mike Pattrick wrote:
> On Wed, Feb 1, 2023 at 10:19 AM Singh, Aman Deep
> <aman.deep.singh@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.

Yes that will be good, to have full implementation in noisy_vnf.c only.

>
>
> Thank you,
> Mike
>
>> Signed-off-by: Mike Pattrick <mkp@redhat.com>
>>
>> ---
>>
>> <snip>