Stephen Hemminger wrote:
> Your excess polling consumes PCI bandwidth which is a fixed resource.
I doubt that this is the problem for three reasons:
* The poll rate would regulate itself if the PCIe bus was the bottleneck
* This problem only occurs with 82599 chips, not with X540 chips
(which
Paul Emmerich wrote:
> Stephen Hemminger wrote:
>
>> Your excess polling consumes PCI bandwidth which is a fixed resource.
>
> I doubt that this is the problem for three reasons:
>
4th: polling should not cause a PCIe access as all the required information is
written
Hi,
I'm working on a DPDK-based packet generator [1] and I recently tried to
upgrade from DPDK 1.7.1 to 2.0.0.
However, I noticed that DPDK 1.7.1 is about 25% faster than 2.0.0 for my use
case.
So I ran some basic performance tests on the l2fwd example with DPDK 1.7.1,
1.8.0 and 2.0.0.
I used an
Hi,
Pablo :
> Could you tell me how you got the L1 cache miss ratio? Perf?
perf stat -e L1-dcache-loads,L1-dcache-misses l2fwd ...
> Could you provide more information on how you run the l2fwd app,
> in order to try to reproduce the issue:
> - L2fwd Command line
./build/l2fwd -c 3 -n 2 -- -p 3
Hi,
sorry, I mixed up the hardware I used for my tests.
Paul Emmerich :
> CPU: Intel(R) Xeon(R) CPU E3-1230 v2
> TurboBoost and HyperThreading disabled.
> Frequency fixed at 3.30 GHz via acpi_cpufreq.
The CPU frequency was fixed at 1.60 GHz to enforce
a CPU bottleneck.
My original
Hi,
Matthew Hall :
> Not sure if it's relevant or not, but there was another mail claiming PCIe
> MSI-X wasn't necessarily working in DPDK 2.x. Not sure if that could be
> causing slowdowns when there are drastic volumes of 64-byte packets causing a
> lot of PCI activity.
Interrupts should not
Hi,
De Lara Guarch, Pablo :
> Could you tell me which changes you made here? I see you are using simple tx
> code path on 1.8.0,
> but with the default values, you should be using vector tx,
> unless you have changed anything in the tx configuration.
sorry, I might have written that down wron
Hi,
this is a follow-up to my post from 3 weeks ago [1]. I'm starting a new
thread here since I now got a completely new test setup for improved
reproducibility.
Background for anyone that didn't catch my last post:
I'm investigating a performance regression in my packet generator [2]
that occ
Hi Luke,
thanks for your suggestion, I actually looked at how your packet
generator in SnabbSwitch works before and it's quite clever. But
unfortunately that's not what I'm looking for.
I'm looking for a generic solution that works with whatever NIC is
supported by DPDK and I don't want to wri
Paul Emmerich:
> I naively tried to move the pool pointer into the first cache line in
> the v2.0.0 tag and the performance actually decreased, I'm not yet sure
> why this happens. There are probably assumptions about the cacheline
> locations and prefetching in the code that
this improves the throughput of a simple tx-only application by 11% in
the full-featured ixgbe tx path and by 14% in the simple tx path.
---
lib/librte_mbuf/rte_mbuf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index ab6de67..f6895b4
Found a really simple solution that almost restores the original
performance: just add a prefetch on alloc. For some reason, I assumed
that this was already done since the troublesome commit I investigated
mentioned something about prefetching... I guess the commit referred to
the hardware pref
ignore them*.
Is this a bug? Or are we using something wrong? (The filter API doesn't
seem to be very well documented)
Paul
Paul Emmerich:
> Hi,
>
> we are trying to use flex filters to match on payload bytes and our code
> stopped working with the new Filter API afte
This patch adds a new tx checksum offloading flag: PKT_TX_NO_CRC_CSUM.
This allows disabling CRC checksum offloading on a per-packet basis.
Doing this can be useful if you want to send out invalid packets on
purpose, e.g. in a packet generator/test framework.
Paul Emmerich (3):
add tx crc
Signed-off-by: Paul Emmerich
---
lib/librte_mbuf/rte_mbuf.c | 1 +
lib/librte_mbuf/rte_mbuf.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index f506517..744fb4e 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf
Signed-off-by: Paul Emmerich
---
drivers/net/i40e/i40e_rxtx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 40cffc1..52f7955 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e
Signed-off-by: Paul Emmerich
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 57c9430..800e224 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib
Hi,
I'm using the per-queue rate control feature found in ixgbe-style NICs
(rte_eth_set_queue_rate_limit) quite extensively in my packet generator
MoonGen.
I've read some parts of the XL710 datasheet and I guess it should be
possible to implement this for this chip. I think there are two ways
Hi,
here's a kind of late follow-up. I've only recently found the need
(mostly for the better support of XL710 NICs (which I still dislike but
people are using them...)) to seriously address DPDK 2.x support in MoonGen.
On 13.05.15 11:03, Ananyev, Konstantin wrote:
> Before start to discuss you
19 matches
Mail list logo
