[dpdk-dev] Possible bug in mlx5_tx_burst_mpw?

Hi Adrien, Thanks for taking the time to write a detailed reply. This indeed sounds reasonable to me. Users will need to take these special-cases into account when predicting performance on their own anticipated workloads, which is a bit tricky, but then that is life when dealing with complex new

[dpdk-dev] Possible bug in mlx5_tx_burst_mpw?

Hi Adrien, On 14 September 2016 at 16:30, Adrien Mazarguil wrote: > Your interpretation is correct (this is intentional and not a bug). > Thanks very much for clarifying. This is interesting to me because I am also working on a ConnectX-4 (Lx) driver based on the newly released driver

[dpdk-dev] Possible bug in mlx5_tx_burst_mpw?

Howdy, Just noticed a line of code that struck me as odd and so I am writing just in case it is a bug: http://dpdk.org/browse/dpdk/tree/drivers/net/mlx5/mlx5_rxtx.c#n1014 Specifically the check "(mpw.length != length)" in mlx_tx_burst_mpw() looks like a descriptor-format optimization for the

[dpdk-dev] [PATCH] vhost: flush used->idx update before reading avail->flags

On 9 June 2015 at 10:46, Michael S. Tsirkin wrote: > By the way, similarly, host side must re-check avail idx after writing > used flags. I don't see where snabbswitch does it - is that a bug > in snabbswitch? Good question. Snabb Switch does not use interrupts from the guest. We always set

[dpdk-dev] [PATCH] vhost: flush used->idx update before reading avail->flags

On 9 June 2015 at 09:04, Linhaifeng wrote: > On 2015/4/24 15:27, Luke Gorrie wrote: > > You should be able to test it like this: > > > > 1. Boot two Linux kernel (e.g. 3.13) guests. > > 2. Connect them via vhost switch. > > 3. Run continuous traffic between t

[dpdk-dev] FW: Vhost user no connection vm2vm

On 22 May 2015 at 10:05, Maciej Grochowski wrote: > What I'm going to do today is to compile newest kernel for vhost and guest > and debug where packet flow stuck, I will report the result > Compiling the guest virtio-net driver with debug printouts enabled can be really helpful in these

[dpdk-dev] TX performance regression caused by the mbuf cachline split

Hi Paul, On 11 May 2015 at 02:14, Paul Emmerich wrote: > Another possible solution would be a more dynamic approach to mbufs: Let me suggest a slightly more extreme idea for your consideration. This method can easily do > 100 Mpps with one very lightly loaded core. I don't know if it works

[dpdk-dev] Beyond DPDK 2.0

On 8 May 2015 at 11:42, Bruce Richardson wrote: > The code in those directories is "common" code that is maintained by Intel > - > which is why you see repeated comments about not modifying it for DPDK. It > is > just contained in it's own subfolder in each DPDK driver for easier > updating >

[dpdk-dev] Beyond DPDK 2.0

Hi Bruce, On 8 May 2015 at 11:06, Bruce Richardson wrote: > For the Intel NIC drivers, the hardware setup part used in DPDK is based > off > the other Intel drivers for other OS's. The code you are interested in > should > therefore be contained within the subfolders off each individual PMD. As

[dpdk-dev] Beyond DPDK 2.0

On 8 May 2015 at 06:16, Wiles, Keith wrote: > The PMDs or drivers would not be useful without DPDK MBUFS IMO > Surprisingly perhaps, I would find them very useful. To me there are two parts to a driver: the hardware setup and the transmit/receive. The hardware setup is complex and generic.

[dpdk-dev] Beyond DPDK 2.0

On 7 May 2015 at 16:02, Avi Kivity wrote: > One problem we've seen with dpdk is that it is a framework, not a library: > it wants to create threads, manage memory, and generally take over. This > is a problem for us, as we are writing a framework (seastar, [1]) and need > to create threads,

[dpdk-dev] Beyond DPDK 2.0

Hi Neil, Thanks for taking the time to reflect on my ideas. On 24 April 2015 at 19:00, Neil Horman wrote: > DPDK will always be > something of a niche market for user to whoom every last ounce of > performance is > the primary requirement This does seem like an excellent position. It is

[dpdk-dev] Beyond DPDK 2.0

Hi Tim, On 16 April 2015 at 12:38, O'Driscoll, Tim wrote: > Following the launch of DPDK by Intel as an internal development project, > the launch of dpdk.org by 6WIND in 2013, and the first DPDK RPM packages > for Fedora in 2014, 6WIND, Red Hat and Intel would like

[dpdk-dev] [PATCH] vhost: flush used->idx update before reading avail->flags

On 24 April 2015 at 03:01, Linhaifeng wrote: > If not add memory fence what would happen? Packets loss or interrupt > loss?How to test it ? > You should be able to test it like this: 1. Boot two Linux kernel (e.g. 3.13) guests. 2. Connect them via vhost switch. 3. Run continuous traffic

[dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?

Howdy, On 8 April 2015 at 17:15, Xie, Huawei wrote: > luke: > 1. host read the flag. 2 guest toggles the flag 3.guest checks the used. > 4. host update used. > Is this your case? > Yep, that is exactly the case I mean. Cheers, -Luke

[dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?

On 7 April 2015 at 17:30, Michael S. Tsirkin wrote: > Just guessing from the available info: > > I think you refer to this: > The driver MUST handle spurious interrupts from the device. > > The intent is to be able to handle some spurious interrupts once in a > while. AFAIK linux

[dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?

Hi Michael, I'm writing to follow up the previous discussion about memory barriers in virtio-net device implementations, and Cc'ing the DPDK list because I believe this is relevant to them too. First, thanks again for getting in touch and reviewing our code. I have now found a missed case where

[dpdk-dev] [snabb-devel] RE: [PATCH 0/4] DPDK memcpy optimization

Hi again John, Thank you for the patient answers :-) Thank you for pointing this out: I was mistakenly testing your Sandy Bridge code on Haswell (lacking -DRTE_MACHINE_CPUFLAG_AVX2). Correcting that, your code is both the fastest and the smallest in my humble micro benchmarking tests. Looks

[dpdk-dev] [PATCH 0/4] DPDK memcpy optimization

On 26 January 2015 at 02:30, Wang, Zhihong wrote: > Hi Luke, > > > > I?m very glad that you?re interested in this work. J > Great :). I never published any performance data, and haven?t run cachebench. > > We use test_memcpy_perf.c in DPDK to do the test mainly, because it?s the >

[dpdk-dev] [PATCH 0/4] DPDK memcpy optimization

On 22 January 2015 at 14:29, Jay Rolette wrote: > Microseconds matter. Scaling up to 100GbE, nanoseconds matter. > True. Is there a cut-off point though? Does one nanosecond matter? AVX512 will fit a 64-byte packet in one register and move that to or from memory with one instruction. L1/L2

[dpdk-dev] [PATCH 0/4] DPDK memcpy optimization

Howdy! This memcpy discussion is absolutely fascinating. Glad to be a fly on the wall! On 21 January 2015 at 22:25, Jim Thompson wrote: > > The differences with DPDK are that a) entire cores (including the AVX/SSE > units and even AES-NI (FPU) are dedicated to DPDK, and b) DPDK is a library, >

[dpdk-dev] bifurcated driver

On 5 November 2014 at 14:00, Thomas Monjalon wrote: > It seems to be close to the bifurcated driver needs. > Not sure if it can solve the security issues if there is no dedicated MMU > in the NIC. > > I feel we should sum up pros and cons of > - igb_uio > - uio_pci_generic >

[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

Hi Tim, On 22 October 2014 15:48, O'driscoll, Tim wrote: > 2.0 (Q1 2015) DPDK Features: > Bifurcated Driver: With the Bifurcated Driver, the kernel will retain > direct control of the NIC, and will assign specific queue pairs to DPDK. > Configuration of the NIC is

[dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04

Hi Pablo, On 24 July 2014 12:33, De Lara Guarch, Pablo wrote: > I think you are seeing the same error as other people are seeing for > DPDK-1.7 on Ubuntu 14.04. > Are you using kernel 3.13.0-24 or 3.13.0-30/32? > Thanks for the quick response. I'm currently using kernel 3.13.0-24.

[dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04

Howdy! I am having trouble building Pktgen-DPDK from Github on Ubuntu 14.04. Is this supported? If so, would anybody tell me how to get the build working? I have tried to be faithful to the instructions in README.md and I have tested with both master and the latest release tag (pktgen-2.7.1).