On Mon, Oct 23, 2017 at 10:06:36AM +0800, Jason Wang wrote:

On 2017年10月19日 04:17, Matthew Rosato wrote:

quoted

quoted

2. It might be useful to short the traffic path as a reference, What I am running
is briefly like:
     pktgen(host kernel) -> tap(x) -> guest(DPDK testpmd)

The bridge driver(br_forward(), etc) might impact performance due to my personal
experience, so eventually I settled down with this simplified testbed which fully
isolates the traffic from both userspace and host kernel stack(1 and 50 instances,
bridge driver, etc), therefore reduces potential interferences.

The down side of this is that it needs DPDK support in guest, has this ever be
run on s390x guest? An alternative approach is to directly run XDP drop on
virtio-net nic in guest, while this requires compiling XDP inside guest which needs
a newer distro(Fedora 25+ in my case or Ubuntu 16.10, not sure).

I made an attempt at DPDK, but it has not been run on s390x as far as
I'm aware and didn't seem trivial to get working.

So instead I took your alternate suggestion & did:
pktgen(host) -> tap(x) -> guest(xdp_drop)

When running this setup, I am not able to reproduce the regression.  As
mentioned previously, I am also unable to reproduce when running one end
of the uperf connection from the host - I have only ever been able to
reproduce when both ends of the uperf connection are running within a guest.

Thanks for the test. Looking at the code, the only obvious difference when
BATCH is 1 is that one spinlock which was previously called by
tun_peek_len() was avoided since we can do it locally. I wonder whether or
not this speeds up handle_rx() a little more then leads more wakeups during
some rates/sizes of TCP stream. To prove this, maybe you can try:

- enable busy polling, using poll-us=1000, and to see if we can still get
the regression
- measure the pps pktgen(vm1) -> tap1 -> bridge -> tap2 -> vm2

Michael, any another possibility in your mind?

Thanks

Not really. I still suspect since it's s390 only there's
some kind of race condition where we wake up a task repeatedly.

-- 
MST