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: 1. (on io) cd /opt/dts 2. export DTS_CFG_FOLDER='conf_100g' - conf_100g has the new configuration files to use the new PCI id and pktgen config file 3. ./dts -s Thanks for your help, Brandon On Tue, Aug 4, 2020 at 12:38 PM Ajit Khaparde 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