On 03/16/2017 08:51 PM, Ben Greear wrote:
I think we can, might take us a day or two to get time to do it.
Thanks,
Ben
On 03/16/2017 08:05 PM, Alexander Duyck wrote:
I'm not really interested in installing a custom version of pktgen.
Any chance you can recreate the issue with standard pktgen?
I think we can, might take us a day or two to get time to do it.
Thanks,
Ben
On 03/16/2017 08:05 PM, Alexander Duyck wrote:
I'm not really interested in installing a custom version of pktgen.
Any chance you can recreate the issue with standard pktgen?
You might try running perf to get a snapsh
I'm actually using a hacked up version of pktgen nicely driven by our
GUI tool, but the crux is that you need to set min and max src IP to some large
range.
We are driving pktgen from a separate machine. Stock pktgen isn't good at
reporting
received pkts last I checked, so it may be more diffic
I'm not really interested in installing a custom version of pktgen.
Any chance you can recreate the issue with standard pktgen?
You might try running perf to get a snapshot of what is using CPU time
on the system. It will probably give you a pretty good idea where the
code is that is eating up al
Can you include the pktgen script you are running?
Also when you say you are driving traffic through the bridge are you
sending from something external on the system or are you actually
directing the traffic from pktgen into the bridge directly?
- Alex
On Thu, Mar 16, 2017 at 3:49 PM, Ben Greear
Hello,
We notice that when using two igb ports as a bridge, if we use pktgen to
drive traffic through the bridge and randomize (or use a very large range)
for the source IP addr in pktgen, then performance of igb is very poor (like
150Mbps
throughput instead of 1Gbps). It runs right at line spe
