[dpdk-dev] [vmxnet3-usermap PATCH 05/16] pmd: allow to build outside of the source directory

2014-03-26 Thread Thomas Monjalon
2014-02-24 10:13, Chris Wright: > * Thomas Monjalon (thomas.monjalon at 6wind.com) wrote: > > S specify source directory (when not already in). > > O specify output directory (when different of current one). > > Thanks for adding docs into help too. Looks good to me. > > Acked-by: Chris Wright

[dpdk-dev] RES: l2fwd high latency/delay

2014-03-26 Thread Fred Pedrisa
It is just a ping test, from one PC to another, using 2 ports as a L2 Bridge. 64 bytes from 192.168.2.249: icmp_seq=967 ttl=128 time=1630 ms 64 bytes from 192.168.2.249: icmp_seq=968 ttl=128 time=5005 ms 64 bytes from 192.168.2.249: icmp_seq=969 ttl=128 time=4004 ms 64 bytes from 192.168.2.249:

[dpdk-dev] l2fwd high latency/delay

2014-03-26 Thread Fred Pedrisa
Hi, I am testing l2fwd in FreeBSD and I am noticing a delay of around 0~3 seconds, what could be causing this behavior ? Fred

[dpdk-dev] [memnic PATCH 5/5] pmd: handle multiple segments on xmit

2014-03-26 Thread Olivier MATZ
Hi Hiroshi-san, On 03/11/2014 06:40 AM, Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > The current MEMNIC PMD cannot handle multiple segments. > > Add the functionality to transmit a mbuf which has multiple segments. > Walk every segment in transmitting mbuf and copy the data to MEMNIC

[dpdk-dev] [memnic PATCH 1/5] pmd: fix race condition

2014-03-26 Thread Olivier MATZ
Hi Hiroshi-san, Please see my comments below. On 03/11/2014 06:37 AM, Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > There is a race condition, on transmit to vSwitch. I think we should not talk specifically about vSwitch, as another implementation of host memnic is possible. Maybe

[dpdk-dev] [PATCH] mk: fix dependencies when modifying config

2014-03-26 Thread Olivier MATZ
Hi Thomas, On 03/19/2014 12:36 PM, Thomas Monjalon wrote: > If .config file is changed and .depdirs was built before, > it must be updated. > It is now done silently (-s) in checkconfig rule. > Now .depdirs is not redone if .config is older. > > It has been tested by enabling PMD_PCAP after a

[dpdk-dev] hw.nic_uio.bdfs

2014-03-26 Thread Masaru Oki
> By default nic_uio takes all the NICs for itself... Yes. I think nic_uio_probe should check hw.nic_uio.bdfs. 2014-03-26 15:49 GMT+09:00 Fred Pedrisa : > Hello, > > > > By default nic_uio takes all the NICs for itself... > > > > So in theory, you needed an option to reserve some NIC ports to

[dpdk-dev] hw.nic_uio.bdfs

2014-03-26 Thread Masaru Oki
avoid??? want you hw.nic_uio.avoid_bdfs? nic_uio behavior I guessed 1. detach kernel driver specified by hw.nic_uio.bdfs 2. attach nic_uio driver for all NICs not attached. but 2. is not correct, I think. 2014-03-26 15:20 GMT+09:00 Fred Pedrisa : > Hello, > > > > You did not understand the

[dpdk-dev] hw.nic_uio.bdfs

2014-03-26 Thread Masaru Oki
Hi, I tried with Intel version 1.6.0 and FreeBSD 9.2-RELEASE on VMware Player. kldload nic_uio by hand, works fine. But kldunload nic_uio only detach uio driver, don't re-attach kernel driver. [oki@ ~]$ cat /boot/loader.conf ## ###

[dpdk-dev] [vmxnet3-usermap PATCH 04/16] pmd: add make help

2014-03-26 Thread Thomas Monjalon
2014-02-24 10:17, Chris Wright: > * Thomas Monjalon (thomas.monjalon at 6wind.com) wrote: > > Add help for quick tips. > > Also define CC and remove RTE_CONFIG variable. > > Straight forward addition of help text (useful, thanks) and simple clean > up. Looks good to me. > > Acked-by: Chris

[dpdk-dev] [PATCH] ixgbe: support flow director for X540

2014-03-26 Thread Thomas Monjalon
> > From: Mauro Annarumma > > > > Flow director in X540 uses the same registers as in 82599. > > So it just has to be enabled in the 82599 implementation. > > > > Signed-off-by: Mauro Annarumma > > Acked-by: Maxime Leroy Applied for version 1.6.0r2. Thank you Mauro and Maxime. -- Thomas

[dpdk-dev] [PATCH] ixgbe: support flow director for X540

2014-03-26 Thread Maxime Leroy
Thanks On Mon, Mar 24, 2014 at 10:35 PM, Thomas Monjalon wrote: > From: Mauro Annarumma > > Flow director in X540 uses the same registers as in 82599. > So it just has to be enabled in the 82599 implementation. > > Signed-off-by: Mauro Annarumma > > Acked-by: Maxime Leroy

[dpdk-dev] RES: RES: RES: hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Oh, don't forget to make : static char bdf_str[1024]; Anywhere in the nic_uio.c file, so this way the other methods can check the content :-) And remove the local declaration from nic_uio_load. -Mensagem original- De: dev [mailto:dev-bounces at dpdk.org] Em nome de Fred Pedrisa

[dpdk-dev] RES: RES: hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Hello, Here is my fix for probe code : static int nic_uio_probe (device_t dev) { int i, len; char *remaining; long bus = 0, device = 0, function = 0; remaining = bdf_str; len = strlen(remaining); for (i = 0; remaining && len >= 5 && i < len;i+=6)

[dpdk-dev] RES: hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Hello, Yes, I am writing a fix for this too ;) De: Masaru Oki [mailto:m-oki at stratosphere.co.jp] Enviada em: quarta-feira, 26 de mar?o de 2014 04:08 Para: Fred Pedrisa Cc: dev at dpdk.org Assunto: Re: [dpdk-dev] hw.nic_uio.bdfs > By default nic_uio takes all the NICs for itself Yes.

[dpdk-dev] RES: RES: hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Hello, Anyways, here is my proposition for this code : static void nic_uio_load(void) { char *remaining; long bus = 0, device = 0, function = 0; char bdf_str[1024]; int i, j, len; device_t dev; memset(bdf_str, 0, sizeof(bdf_str));

[dpdk-dev] RES: hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Hello, By default nic_uio takes all the NICs for itself So in theory, you needed an option to reserve some NIC ports to your system, without DPDK taking it for itself De: Masaru Oki [mailto:m-oki at stratosphere.co.jp] Enviada em: quarta-feira, 26 de mar?o de 2014 03:43 Para: Fred

[dpdk-dev] RES: hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Hello, You did not understand the purpose of that parameter, it is made to ?avoid? nic_uio from pursuing the wanted NICs... so they are free to be used in the system :) Right now the code to handle it is wrong and I am trying to fix it myself. De: Masaru Oki [mailto:m-oki at

[dpdk-dev] hw.nic_uio.bdfs

2014-03-26 Thread Fred Pedrisa
Hi, guys. This variable is not working as intended for FreeBSD :( It does not dettach nic_uio from the wanted ports :/