On Wed, Feb 1, 2023 at 10:19 AM Singh, Aman Deep <aman.deep.si...@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 <m...@redhat.com> > > --- > > <snip>
