From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 36607A04AC for ; Tue, 1 Sep 2020 20:12:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 07AC61C0B1; Tue, 1 Sep 2020 20:12:14 +0200 (CEST) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by dpdk.org (Postfix) with ESMTP id 9B1BA1C0B0 for ; Tue, 1 Sep 2020 20:12:12 +0200 (CEST) Received: by mail-ot1-f45.google.com with SMTP id 37so1988857oto.4 for ; Tue, 01 Sep 2020 11:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8WlDhOxtu0hyezP2YOdAgh0ZIbIaw+kg9MCw2Rr20Ww=; b=VObKs+b3AXQoHxSC5dzFVuTSGB7SpCrcqXmxGAdK1auPOlvPE6QMSzJgxQ3qz33WO6 ME6/uvZcSXHzGdI1R6CPH0FxX7Is58Pl+AENN5pRtVsRNvH5RvVXacZw7Eet8HVlOm+S MpYrfC33/HwusmbeJhkAh1MEkfaqbOH5Wo/Ws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8WlDhOxtu0hyezP2YOdAgh0ZIbIaw+kg9MCw2Rr20Ww=; b=YwathX1rBfKgsb/pxINmsn1FNxhx8BGAsyKP6NekXEmRQTzfxyS16uQrlrmdm6f5Tz Y+VuTTxzm7pDdXdCFOCmJ2SQ1rqOkzAAOjyUkjLPPWkrYqv1OBYR6/HBEwcPxjgClZkr 0+/ZY4Z5SRCm13AqpkwzzmUnnMPg+Yzrmu/oQq5UhYVIMBcFupipwS+ylyZ2jXWyxXoW Cp1ePVIvsXVI2M9iRl/1UXdbS56fWaTbGRnQx2Kpxiqv3KsxwO9nKtrDhsuP5QdDnZZp vqvcSmruPhQGb7gxvpHpCOBHbto7Czfb/Aco4LptUKGycyQ5IRy9na9w+DYlwbm6P/Eq HYuw== X-Gm-Message-State: AOAM531HnXRCCL0EDagKH5Sv6BYBU+8faNqaXUXR25Hk4FTkqPkad7ZC tzL7a0bsiZZVf5BYLeKiw4FurtidgeIrsOztSrVDXg== X-Google-Smtp-Source: ABdhPJxjH6uOmB72/cdxUis+rFnvRDQbMY8wvQF7JuiwHeeXptzijs3HE1Si0i25XKFNbGY3vrRr9jmxMdc5q5jAhGE= X-Received: by 2002:a9d:ae7:: with SMTP id 94mr2433904otq.283.1598983931748; Tue, 01 Sep 2020 11:12:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ajit Khaparde Date: Tue, 1 Sep 2020 11:11:55 -0700 Message-ID: To: Brandon Lo Cc: ci@dpdk.org, dpdklab Content-Type: multipart/alternative; boundary="00000000000041292905ae447516" Subject: Re: [dpdk-ci] New 100G Broadcom NIC Ubuntu X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Sender: "ci" --00000000000041292905ae447516 Content-Type: text/plain; charset="UTF-8" Hi Brandon, Thanks for this. I have been stretched thin lately, and this will surely help. Thanks Ajit On Tue, Sep 1, 2020 at 11:09 AM Brandon Lo wrote: > Hi Ajit, > > I'm going to re-enable the Broadcom 25G NIC in production performance > and functional testing. > > If you would like to do testing/debugging on the machine, such as on > the 100G NIC, then please disable these two pipelines on our Jenkins: > > https://dpdklab.iol.unh.edu/jenkins/job/Broadcom-25G-Functional-Test-Pipeline/ > > https://dpdklab.iol.unh.edu/jenkins/job/Broadcom-25G-Performance-Test-Pipeline/ > > You will need to sign in using the same credentials as your VPN. > > This will prevent any overlapping of DTS/TREX runs which is known to > cause errors. > Please let me know if you run into any issues. > > Thanks, > Brandon > > On Wed, Aug 26, 2020 at 3:58 PM Ajit Khaparde > wrote: > > > > Not yet Brandon. > > But I believe I might have to look at what trex is doing to make > progress. > > I will let you know if I need any help. > > > > Thanks > > Ajit > > > > On Tue, Aug 25, 2020 at 1:13 PM Brandon Lo wrote: > >> > >> Hi Ajit, > >> > >> Did you find anything of interest on the machine? > >> I could help out if needed. > >> > >> Thanks, > >> Brandon > >> > >> On Thu, Aug 20, 2020 at 5:07 PM Ajit Khaparde > >> wrote: > >> > > >> > Hi Brandon, > >> > I do see some issues while running trex on this setup. > >> > I will have to dig further. I will let you know once I find something > or may be a fix. > >> > > >> > Thanks > >> > Ajit > >> > > >> > On Thu, Aug 20, 2020 at 8:39 AM Brandon Lo wrote: > >> >> > >> >> Hi Ajit, > >> >> > >> >> I believe DTS/TREX is run on the io machine as a tester. Rhea runs > >> >> testpmd (through an ssh session from io --> rhea) to catch > information > >> >> as a DUT. > >> >> > >> >> The only commands that I run (on io) are: > >> >> cd /opt/dts > >> >> export DTS_CFG_FOLDER='conf_100g' > >> >> ./dts -s > >> >> > >> >> The rest is managed by DTS itself. > >> >> The issue occurs when DTS is trying to send packets to rhea from io > on > >> >> the new 100G NIC. > >> >> It seems to happen after it tries to measure throughput using TREX's > API. > >> >> > >> >> Thanks, > >> >> Brandon > >> >> > >> >> On Thu, Aug 20, 2020 at 12:29 AM Ajit Khaparde > >> >> wrote: > >> >> > > >> >> > Hi Brandon, > >> >> > I was trying to see what exactly is happening on the setup and > what is causing the problem. > >> >> > But I will need your help to use the proper code and commands. > >> >> > > >> >> > I believe you run the testpmd command on io. And the trex is > executed on rhea? > >> >> > Can you point me to the location of the code and the steps you are > following while running the test? > >> >> > > >> >> > Thanks > >> >> > Ajit > >> >> > > >> >> > On Tue, Aug 11, 2020 at 10:47 AM Ajit Khaparde < > ajit.khaparde@broadcom.com> wrote: > >> >> >> > >> >> >> Hi Brandon, > >> >> >> I haven't. I tried to login as well. But I had some issues doing > it from the office. > >> >> >> I just have to remind myself to try it again once I get home > before I connect to the company VPN. > >> >> >> Thanks for checking in. I will try to update you as soon as I can. > >> >> >> > >> >> >> Thanks > >> >> >> Ajit > >> >> >> > >> >> >> On Tue, Aug 11, 2020 at 10:46 AM Brandon Lo > wrote: > >> >> >>> > >> >> >>> Hi Ajit, > >> >> >>> > >> >> >>> I'm just checking in; have you heard of any updates on this > issue? > >> >> >>> > >> >> >>> Thanks, > >> >> >>> Brandon > >> >> >>> > >> >> >>> On Tue, Aug 4, 2020 at 1:42 PM Brandon Lo > wrote: > >> >> >>>> > >> >> >>>> Hi Ajit, > >> >> >>>> > >> >> >>>> Yes, I believe the issue is coming from the trex/tester system > with the 100G NIC. > >> >> >>>> I'm not sure what causes this issue; if I run trex using the > command "cd /opt/v2.82;./t-rex-64 -i --cfg /etc/trex_cfg_100g.yaml -c 7", > which is the same command used in DTS, it seems to launch without failing. > >> >> >>>> > >> >> >>>> If you want to replicate it, here are the steps that I ran: > >> >> >>>> > >> >> >>>> (on io) cd /opt/dts > >> >> >>>> export DTS_CFG_FOLDER='conf_100g' > >> >> >>>> > >> >> >>>> conf_100g has the new configuration files to use the new PCI id > and pktgen config file > >> >> >>>> > >> >> >>>> ./dts -s > >> >> >>>> > >> >> >>>> > >> >> >>>> Thanks for your help, > >> >> >>>> Brandon > >> >> >>>> > >> >> >>>> On Tue, Aug 4, 2020 at 12:38 PM Ajit Khaparde < > ajit.khaparde@broadcom.com> wrote: > >> >> >>>>> > >> >> >>>>> Hi Brandon, > >> >> >>>>> No, I haven't seen or heard this before. > >> >> >>>>> But I will try to have someone run it again. > >> >> >>>>> > >> >> >>>>> Just to make sure - > >> >> >>>>> You are running trex on the 100G NIC and the problem is > encountered on that setup? > >> >> >>>>> Or is it the system that is running testpmd where you are > running into the issue? > >> >> >>>>> > >> >> >>>>> Thanks > >> >> >>>>> Ajit > >> >> >>>>> > >> >> >>>>> On Tue, Aug 4, 2020 at 9:16 AM Brandon Lo > wrote: > >> >> >>>>>> > >> >> >>>>>> Hi Ajit, > >> >> >>>>>> > >> >> >>>>>> I'm running into a problem with trying to run > nic_single_core_perf on the new NIC. > >> >> >>>>>> The current configuration uses trex version v2.82. > >> >> >>>>>> However, I'm running into an error when it tries to actually > do a test case in the nic_single_core_perf. > >> >> >>>>>> > >> >> >>>>>> The output looks like this when it reaches a test case: > >> >> >>>>>> > >> >> >>>>>>> TestNicSingleCorePerf: Test running at parameters: > framesize: 64, rxd/txd: 512 > >> >> >>>>>>> dut.rhea: > ./x86_64-native-linuxapp-gcc/app/testpmd -l 16,17 -n 4 -w 0000:81:00.0 -w > 0000:81:00.1 --file-prefix=dpdk_11307_20200804160513 -- -i > --portmask=0x3 --txd=512 --rxd=512 > >> >> >>>>>>> dut.rhea: start > >> >> >>>>>>> TestNicSingleCorePerf: Test Case > test_perf_nic_single_core Result ERROR: Traceback (most recent call last): > >> >> >>>>>>> File "/opt/dts/framework/test_case.py", line 316, in > _execute_test_case > >> >> >>>>>>> case_obj() > >> >> >>>>>>> File "tests/TestSuite_nic_single_core_perf.py", line 198, > in test_perf_nic_single_core > >> >> >>>>>>> self.perf_test(self.nb_ports) > >> >> >>>>>>> File "tests/TestSuite_nic_single_core_perf.py", line 259, > in perf_test > >> >> >>>>>>> _, packets_received = > self.tester.pktgen.measure_throughput(stream_ids=streams, > options=traffic_opt) > >> >> >>>>>>> File "/opt/dts/framework/pktgen_base.py", line 245, in > measure_throughput > >> >> >>>>>>> self._prepare_transmission(stream_ids=stream_ids) > >> >> >>>>>>> File "/opt/dts/framework/pktgen_trex.py", line 779, in > _prepare_transmission > >> >> >>>>>>> self._conn.reset(ports=self._ports) > >> >> >>>>>>> File > "/opt/v2.82/automation/trex_control_plane/interactive/trex/common/trex_api_annotators.py", > line 51, in wrap2 > >> >> >>>>>>> ret = f(*args, **kwargs) > >> >> >>>>>>> File > "/opt/v2.82/automation/trex_control_plane/interactive/trex/stl/trex_stl_client.py", > line 339, in reset > >> >> >>>>>>> self.clear_stats(ports) > >> >> >>>>>>> File > "/opt/v2.82/automation/trex_control_plane/interactive/trex/common/trex_api_annotators.py", > line 51, in wrap2 > >> >> >>>>>>> ret = f(*args, **kwargs) > >> >> >>>>>>> File > "/opt/v2.82/automation/trex_control_plane/interactive/trex/stl/trex_stl_client.py", > line 1467, in clear_stats > >> >> >>>>>>> self._clear_stats_common(ports, clear_global, > clear_xstats) > >> >> >>>>>>> File > "/opt/v2.82/automation/trex_control_plane/interactive/trex/common/trex_client.py", > line 2840, in _clear_stats_common > >> >> >>>>>>> raise TRexError(rc) > >> >> >>>>>>> trex.common.trex_exceptions.TRexError: *** [RPC] - Failed to > get server response from tcp://127.0.0.1:4501 > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> I have found one similar case on the github repository for > trex, but the solution was vendor-specific: > https://github.com/cisco-system-traffic-generator/trex-core/issues/147. > >> >> >>>>>> Have you ran into this issue before? > >> >> >>>>>> > >> >> >>>>>> Thanks, > >> >> >>>>>> Brandon > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> -- > >> >> >>>> > >> >> >>>> Brandon Lo > >> >> >>>> > >> >> >>>> UNH InterOperability Laboratory > >> >> >>>> > >> >> >>>> 21 Madbury Rd, Suite 100, Durham, NH 03824 > >> >> >>>> > >> >> >>>> blo@iol.unh.edu > >> >> >>>> > >> >> >>>> www.iol.unh.edu > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> > >> >> >>> Brandon Lo > >> >> >>> > >> >> >>> UNH InterOperability Laboratory > >> >> >>> > >> >> >>> 21 Madbury Rd, Suite 100, Durham, NH 03824 > >> >> >>> > >> >> >>> blo@iol.unh.edu > >> >> >>> > >> >> >>> www.iol.unh.edu > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> Brandon Lo > >> >> > >> >> UNH InterOperability Laboratory > >> >> > >> >> 21 Madbury Rd, Suite 100, Durham, NH 03824 > >> >> > >> >> blo@iol.unh.edu > >> >> > >> >> www.iol.unh.edu > >> > >> > >> > >> -- > >> > >> Brandon Lo > >> > >> UNH InterOperability Laboratory > >> > >> 21 Madbury Rd, Suite 100, Durham, NH 03824 > >> > >> blo@iol.unh.edu > >> > >> www.iol.unh.edu > > > > -- > > Brandon Lo > > UNH InterOperability Laboratory > > 21 Madbury Rd, Suite 100, Durham, NH 03824 > > blo@iol.unh.edu > > www.iol.unh.edu > --00000000000041292905ae447516 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brandon,
Thanks for this.
I have been stretched thin lately, an= d this will surely help.

Thanks
Ajit

On Tue, Sep 1, 2020 at 11:09 A= M Brandon Lo <blo@iol.unh.edu>= wrote:
Hi Ajit,=

I'm going to re-enable the Broadcom 25G NIC in production performance and functional testing.

If you would like to do testing/debugging on the machine, such as on
the 100G NIC, then please disable these two pipelines on our Jenkins:
=C2=A0 =C2=A0 https://= dpdklab.iol.unh.edu/jenkins/job/Broadcom-25G-Functional-Test-Pipeline/<= br> =C2=A0 =C2=A0 https:/= /dpdklab.iol.unh.edu/jenkins/job/Broadcom-25G-Performance-Test-Pipeline/

You will need to sign in using the same credentials as your VPN.

This will prevent any overlapping of DTS/TREX runs which is known to
cause errors.
Please let me know if you run into any issues.

Thanks,
Brandon

On Wed, Aug 26, 2020 at 3:58 PM Ajit Khaparde
<ajit.kh= aparde@broadcom.com> wrote:
>
> Not yet Brandon.
> But I believe I might have to look at what trex is doing to make progr= ess.
> I will let you know if I need any help.
>
> Thanks
> Ajit
>
> On Tue, Aug 25, 2020 at 1:13 PM Brandon Lo <blo@iol.unh.edu> wrote:
>>
>> Hi Ajit,
>>
>> Did you find anything of interest on the machine?
>> I could help out if needed.
>>
>> Thanks,
>> Brandon
>>
>> On Thu, Aug 20, 2020 at 5:07 PM Ajit Khaparde
>> <ajit.khaparde@broadcom.com> wrote:
>> >
>> > Hi Brandon,
>> > I do see some issues while running trex on this setup.
>> > I will have to dig further. I will let you know once I find s= omething or may be a fix.
>> >
>> > Thanks
>> > Ajit
>> >
>> > On Thu, Aug 20, 2020 at 8:39 AM Brandon Lo <blo@iol.unh.edu> wrote:
>> >>
>> >> Hi Ajit,
>> >>
>> >> I believe DTS/TREX is run on the io machine as a tester. = Rhea runs
>> >> testpmd (through an ssh session from io --> rhea) to c= atch information
>> >> as a DUT.
>> >>
>> >> The only commands that I run (on io) are:
>> >> cd /opt/dts
>> >> export DTS_CFG_FOLDER=3D'conf_100g'
>> >> ./dts -s
>> >>
>> >> The rest is managed by DTS itself.
>> >> The issue occurs when DTS is trying to send packets to rh= ea from io on
>> >> the new 100G NIC.
>> >> It seems to happen after it tries to measure throughput u= sing TREX's API.
>> >>
>> >> Thanks,
>> >> Brandon
>> >>
>> >> On Thu, Aug 20, 2020 at 12:29 AM Ajit Khaparde
>> >> <ajit.khaparde@broadcom.com> wrote:
>> >> >
>> >> > Hi Brandon,
>> >> > I was trying to see what exactly is happening on the= setup and what is causing the problem.
>> >> > But I will need your help to use the proper code and= commands.
>> >> >
>> >> > I believe you run the testpmd command on io. And the= trex is executed on rhea?
>> >> > Can you point me to the location of the code and the= steps you are following while running the test?
>> >> >
>> >> > Thanks
>> >> > Ajit
>> >> >
>> >> > On Tue, Aug 11, 2020 at 10:47 AM Ajit Khaparde <<= a href=3D"mailto:ajit.khaparde@broadcom.com" target=3D"_blank">ajit.khapard= e@broadcom.com> wrote:
>> >> >>
>> >> >> Hi Brandon,
>> >> >> I haven't. I tried to login as well. But I h= ad some issues doing it from the office.
>> >> >> I just have to remind myself to try it again onc= e I get home before I connect to the company VPN.
>> >> >> Thanks for checking in. I will try to update you= as soon as I can.
>> >> >>
>> >> >> Thanks
>> >> >> Ajit
>> >> >>
>> >> >> On Tue, Aug 11, 2020 at 10:46 AM Brandon Lo <= blo@iol.unh.edu>= ; wrote:
>> >> >>>
>> >> >>> Hi Ajit,
>> >> >>>
>> >> >>> I'm just checking in; have you heard of = any updates on this issue?
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Brandon
>> >> >>>
>> >> >>> On Tue, Aug 4, 2020 at 1:42 PM Brandon Lo &l= t;blo@iol.unh.edu&= gt; wrote:
>> >> >>>>
>> >> >>>> Hi Ajit,
>> >> >>>>
>> >> >>>> Yes, I believe the issue is coming from = the trex/tester system with the 100G NIC.
>> >> >>>> I'm not sure what causes this issue;= if I run trex using the command "cd /opt/v2.82;./t-rex-64 -i --cfg /e= tc/trex_cfg_100g.yaml -c 7", which is the same command used in DTS, it= seems to launch without failing.
>> >> >>>>
>> >> >>>> If you want to replicate it, here are th= e steps that I ran:
>> >> >>>>
>> >> >>>> (on io) cd /opt/dts
>> >> >>>> export DTS_CFG_FOLDER=3D'conf_100g&#= 39;
>> >> >>>>
>> >> >>>> conf_100g has the new configuration file= s to use the new PCI id and pktgen config file
>> >> >>>>
>> >> >>>> ./dts -s
>> >> >>>>
>> >> >>>>
>> >> >>>> Thanks for your help,
>> >> >>>> Brandon
>> >> >>>>
>> >> >>>> On Tue, Aug 4, 2020 at 12:38 PM Ajit Kha= parde <a= jit.khaparde@broadcom.com> wrote:
>> >> >>>>>
>> >> >>>>> Hi Brandon,
>> >> >>>>> No, I haven't seen or heard this= before.
>> >> >>>>> But I will try to have someone run i= t again.
>> >> >>>>>
>> >> >>>>> Just to make sure -
>> >> >>>>> You are running trex on the 100G NIC= and the problem is encountered on that setup?
>> >> >>>>> Or is it the system that is running = testpmd where you are running into the issue?
>> >> >>>>>
>> >> >>>>> Thanks
>> >> >>>>> Ajit
>> >> >>>>>
>> >> >>>>> On Tue, Aug 4, 2020 at 9:16 AM Brand= on Lo <blo@iol.unh.= edu> wrote:
>> >> >>>>>>
>> >> >>>>>> Hi Ajit,
>> >> >>>>>>
>> >> >>>>>> I'm running into a problem w= ith trying to run nic_single_core_perf on the new NIC.
>> >> >>>>>> The current configuration uses t= rex version v2.82.
>> >> >>>>>> However, I'm running into an= error when it tries to actually do a test case in the nic_single_core_perf= .
>> >> >>>>>>
>> >> >>>>>> The output looks like this when = it reaches a test case:
>> >> >>>>>>
>> >> >>>>>>> TestNicSingleCorePerf: Test = running at parameters: framesize: 64, rxd/txd: 512
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dut.rhea: ./x86_64-n= ative-linuxapp-gcc/app/testpmd -l 16,17 -n 4 -w 0000:81:00.0 -w 0000:81:00.= 1=C2=A0 --file-prefix=3Ddpdk_11307_20200804160513=C2=A0 =C2=A0 -- -i=C2=A0 = --portmask=3D0x3 --txd=3D512 --rxd=3D512
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dut.rhea: start
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 TestNicSingleCorePerf: Test Case test_perf_nic_single_core Result ER= ROR: Traceback (most recent call last):
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= dts/framework/test_case.py", line 316, in _execute_test_case
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0case_obj(= )
>> >> >>>>>>>=C2=A0 =C2=A0File "tests= /TestSuite_nic_single_core_perf.py", line 198, in test_perf_nic_single= _core
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0self.perf= _test(self.nb_ports)
>> >> >>>>>>>=C2=A0 =C2=A0File "tests= /TestSuite_nic_single_core_perf.py", line 259, in perf_test
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0_, packet= s_received =3D self.tester.pktgen.measure_throughput(stream_ids=3Dstreams, = options=3Dtraffic_opt)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= dts/framework/pktgen_base.py", line 245, in measure_throughput
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0self._pre= pare_transmission(stream_ids=3Dstream_ids)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= dts/framework/pktgen_trex.py", line 779, in _prepare_transmission
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0self._con= n.reset(ports=3Dself._ports)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= v2.82/automation/trex_control_plane/interactive/trex/common/trex_api_annota= tors.py", line 51, in wrap2
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0ret =3D f= (*args, **kwargs)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= v2.82/automation/trex_control_plane/interactive/trex/stl/trex_stl_client.py= ", line 339, in reset
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0self.clea= r_stats(ports)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= v2.82/automation/trex_control_plane/interactive/trex/common/trex_api_annota= tors.py", line 51, in wrap2
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0ret =3D f= (*args, **kwargs)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= v2.82/automation/trex_control_plane/interactive/trex/stl/trex_stl_client.py= ", line 1467, in clear_stats
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0self._cle= ar_stats_common(ports, clear_global, clear_xstats)
>> >> >>>>>>>=C2=A0 =C2=A0File "/opt/= v2.82/automation/trex_control_plane/interactive/trex/common/trex_client.py&= quot;, line 2840, in _clear_stats_common
>> >> >>>>>>>=C2=A0 =C2=A0 =C2=A0raise TRe= xError(rc)
>> >> >>>>>>> trex.common.trex_exceptions.= TRexError: *** [RPC] - Failed to get server response from tcp://127.0.0.1:4501<= /a>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> I have found one similar case on= the github repository for trex, but the solution was vendor-specific: https://github.com/cisco-system-tr= affic-generator/trex-core/issues/147.
>> >> >>>>>> Have you ran into this issue bef= ore?
>> >> >>>>>>
>> >> >>>>>> Thanks,
>> >> >>>>>> Brandon
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>>
>> >> >>>> Brandon Lo
>> >> >>>>
>> >> >>>> UNH InterOperability Laboratory
>> >> >>>>
>> >> >>>> 21 Madbury Rd, Suite 100, Durham, NH 038= 24
>> >> >>>>
>> >> >>>> blo@iol.unh.edu
>> >> >>>>
>> >> >>>> www.iol.unh.edu
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>>
>> >> >>> Brandon Lo
>> >> >>>
>> >> >>> UNH InterOperability Laboratory
>> >> >>>
>> >> >>> 21 Madbury Rd, Suite 100, Durham, NH 03824 >> >> >>>
>> >> >>> blo@iol.unh.edu
>> >> >>>
>> >> >>> www.iol.unh.edu
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Brandon Lo
>> >>
>> >> UNH InterOperability Laboratory
>> >>
>> >> 21 Madbury Rd, Suite 100, Durham, NH 03824
>> >>
>> >> blo@= iol.unh.edu
>> >>
>> >> www.iol.unh.edu
>>
>>
>>
>> --
>>
>> Brandon Lo
>>
>> UNH InterOperability Laboratory
>>
>> 21 Madbury Rd, Suite 100, Durham, NH 03824
>>
>> blo@iol.unh.e= du
>>
>> www.iol.unh.edu



--

Brandon Lo

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

blo@iol.unh.edu
www= .iol.unh.edu
--00000000000041292905ae447516--