From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 66CCD41BA2; Wed, 1 Feb 2023 20:03:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1454842B8E; Wed, 1 Feb 2023 20:03:56 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 94FB04067C for ; Wed, 1 Feb 2023 20:03:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675278234; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rP7hx/N5v8MdBQg+iVfzXvCCitDROEJNR1sC14uuTJM=; b=fRoUmV4criCjwjO8WtxsT9gu/1gfEmd22wjUjZkz7FsrMPjCJ5T5fherS/2laSwYq95jtn AaeikxMz1zOmu2J0nYuEUAi8uRGyrwCnQfS5iV/hPg/qyJBTTvhdVEWICuQPFC8Ap8/vRC h2W2TetokAk/a+kpZj7GAVFHAfdcm94= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-641-sQysv9uVPvuTgAL1aujGGg-1; Wed, 01 Feb 2023 14:03:52 -0500 X-MC-Unique: sQysv9uVPvuTgAL1aujGGg-1 Received: by mail-ej1-f69.google.com with SMTP id he34-20020a1709073da200b00887ced84328so7295613ejc.10 for ; Wed, 01 Feb 2023 11:03:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rP7hx/N5v8MdBQg+iVfzXvCCitDROEJNR1sC14uuTJM=; b=FBMTJTAU5mDJW13Q+2lgQAeWpPVODY7sn7IWyl2e+6uCvbVwsDNVLHi2pCKPyjXzSB PsWYzO+y0td6TxicwhOugPvJvAqHHRJxcewi7fQOj/y04EYJnjULEE/M7bx71013MK6y WC9lY3mNnC52MbnbHzDQ0nSscgxjKIEROW/8JfYuLxHpnPN1jk9j8HO1xbveutUZmc7u JoZF8r6Cj9AstMYaAlr9QlrkSoEgzwn/pxEeEbCd6vQ8L9h5DKmy0RG7Y8/fhtBSVTzv LMhuUlgn2s125blzU8YNX6bobQbC0gIMDb6KbuY29D9WlIcnQ/rEBTAaxd9qeobDCvwm eOPQ== X-Gm-Message-State: AO0yUKUrG2RCfiVgqcEkDw4Mq6/5ACoi1JBOfk8PFQimcVMqITSGYxLC OlpBGI6Cu3VxZ/RBZ1JKMWhaG9zr9qXPtu9QwpKp1hFbQokiUTEipzkfjNW3MeN5jB6cCvM3cQM YJgQ4DFCSw56jVEvFP4U= X-Received: by 2002:a17:906:1708:b0:870:1090:66d1 with SMTP id c8-20020a170906170800b00870109066d1mr911927eje.242.1675278231339; Wed, 01 Feb 2023 11:03:51 -0800 (PST) X-Google-Smtp-Source: AK7set887TaXacscCJ6CXY9FLFH5Q3NKMZws7OHXktFvqD0YGZ+e1KlLSa+r5gjULnobOd6xTYfFrPxUMDtlHP7HIV8= X-Received: by 2002:a17:906:1708:b0:870:1090:66d1 with SMTP id c8-20020a170906170800b00870109066d1mr911918eje.242.1675278231123; Wed, 01 Feb 2023 11:03:51 -0800 (PST) MIME-Version: 1.0 References: <20230125224531.162592-1-mkp@redhat.com> <20230126045516.176917-1-mkp@redhat.com> <17cde446-25ff-6f5c-79ef-c3ba5e0a12ea@intel.com> In-Reply-To: <17cde446-25ff-6f5c-79ef-c3ba5e0a12ea@intel.com> From: Mike Pattrick Date: Wed, 1 Feb 2023 14:03:39 -0500 Message-ID: Subject: Re: [PATCH v2] app/testpmd: expand noisy neighbour forward mode support To: "Singh, Aman Deep" Cc: Yuying Zhang , stephen@networkplumber.org, dev@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Feb 1, 2023 at 10:19 AM Singh, Aman Deep 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 > > --- > >