Bug 2250077

Summary: [DPDK checkup] Clearer user output when configured PackerPerSecond doesn't fit the NIC bandwidth
Product: Container Native Virtualization (CNV) Reporter: Yossi Segev <ysegev>
Component: NetworkingAssignee: Petr Horáček <phoracek>
Status: CLOSED MIGRATED QA Contact: Yossi Segev <ysegev>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.14.0CC: ralavi
Target Milestone: ---   
Target Release: 4.15.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-12-14 16:14:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
DPDK checkup resources none

Description Yossi Segev 2023-11-16 14:18:09 UTC
Created attachment 1999825 [details]
DPDK checkup resources

Description of problem:
When running DPDK checkup, and using trafficGenPacketsPerSecond which doesn't fit the bandwidth of the node interface, the failure reason that is output doesn't reflect the actual failure reason from the traffic generator (trex).


Version-Release number of selected component (if applicable):
CNV 4.14.0
Traffic generator quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0


How reproducible:
100%


Steps to Reproduce:
1.
Apply the attached resources (some parameter might have to be modified to fit your cluster).
The last resource is the job resource, and once it is applied - the DPDK checkup starts executing.

2.
Wait for the job to be finished.
As the `trafficGenPacketsPerSecond` parameter in the ConfigMap is quite high, the job should fail (if it doesn't - try a higher value).

3.
Check the output configmap:
$ oc get -f 6-dpdk-checkup-configmap.yaml -o yaml
apiVersion: v1
data:
...
  status.failureReason: no packets were sent from the traffic generator
...
  status.succeeded: "false"


Actual results:
No indication to the user on why no packets were sent from the traffic generator, which require tedious debugging.


Expected results:
A clear message specifying the failure reason.


Additional info:
trex output does include a verbose output, which we should redirect to the client:

start - Port 0 : *** Expected L1 B/W: '5.376 Gbps' exceeds port line rate: '1 Gbps'
(5.376 corresponds to the 8m value that was set, in this example, for the `trafficGenPacketsPerSecond`.

Comment 1 Ram Lavi 2023-11-16 14:27:29 UTC
The error is that the command starting the trex traffic failed but the failure was not collected.
It should be collected and it should fail the checkup with the appropriate err.