Bug 1377222

Summary:	netsniff-ng: drops packets when max CPU is not very high
Product:	Red Hat Enterprise Linux 7	Reporter:	xmu
Component:	netsniff-ng	Assignee:	Paolo Abeni <pabeni>
Status:	CLOSED NOTABUG	QA Contact:	xmu
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	aloughla, atragler, egarver, mleitner, rkhan, sukulkar, xmu
Target Milestone:	rc
Target Release:	---
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:	2017-09-26 09:51:14 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:

Comment 1 Paolo Abeni 2017-09-15 16:44:49 UTC

I'm replicating it on my host using a much longer test period (e.g. -t 1000).

The problem is that with very large captures, we stress a lot the storage and the kernel activity to flush the block device are not accounted to the netsniff-ng process, but to some worker thread.

Increasing the number of netsniff-ng processes decreases the change for this to happen, because introduce more per process 'caching'.

I think this behavior is not a bug, wdyt?
Can you please verify that increasing the iperf run time you can reproduce the issue more frequently even in presence of may netsniff-ng processes?

Thanks,

Paolo

Comment 2 Paolo Abeni 2017-09-21 15:47:46 UTC

Hi,

This is a notice that I'm going to close this bz as not a bug soon, unless you provide some feedback on the above.

Paolo

Comment 3 xmu 2017-09-22 03:41:19 UTC

paolo,
sorry, I missed your comment before, since we are in pegas1.0 snapshot4 testing phase, now I have no machines with 10 NIC in my hand. the machines may be available after 1-2 days or more longer.

I don't mind you close the bug status now, if there is still a problem, I'll contact you and reopen it.

Comment 4 xmu 2017-09-26 09:50:08 UTC

I have tested it again, and I found the CPU can be hit 100%, it's a mistake.
so I think this bug can be closed.
Sorry for the inconvenient

Comment 5 Paolo Abeni 2017-09-26 09:51:14 UTC

as per comment#4