From: Mike Pattrick <mkp@redhat.com>
To: "Singh, Aman Deep" <aman.deep.singh@intel.com>
Cc: Yuying Zhang <yuying.zhang@intel.com>,
stephen@networkplumber.org, dev@dpdk.org
Subject: Re: [PATCH v2] app/testpmd: expand noisy neighbour forward mode support
Date: Wed, 1 Feb 2023 14:03:39 -0500 [thread overview]
Message-ID: <CAHcdBH51okQHmoQyHaN5ywh55Gs2r4pvs4TG+we+hri3_cVEHA@mail.gmail.com> (raw)
In-Reply-To: <17cde446-25ff-6f5c-79ef-c3ba5e0a12ea@intel.com>
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.
Thank you,
Mike
>
> Signed-off-by: Mike Pattrick <mkp@redhat.com>
>
> ---
>
> <snip>
next prev parent reply other threads:[~2023-02-01 19:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 22:45 [PATCH] " Mike Pattrick
2023-01-25 22:56 ` Stephen Hemminger
2023-01-25 22:57 ` Stephen Hemminger
2023-01-26 4:55 ` [PATCH v2] " Mike Pattrick
2023-02-01 15:19 ` Singh, Aman Deep
2023-02-01 19:03 ` Mike Pattrick [this message]
2023-02-08 16:57 ` Singh, Aman Deep
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHcdBH51okQHmoQyHaN5ywh55Gs2r4pvs4TG+we+hri3_cVEHA@mail.gmail.com \
--to=mkp@redhat.com \
--cc=aman.deep.singh@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=yuying.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).