Hello,
Also the same problem happens with : testpmd
64 bytes from 192.168.2.81: icmp_seq=1612 ttl=64 time=1002.400 ms
64 bytes from 192.168.2.81: icmp_seq=1613 ttl=64 time=2833.217 ms
64 bytes from 192.168.2.81: icmp_seq=1614 ttl=64 time=1832.221 ms
64 bytes from 192.168.2.81: icmp_seq=1615 ttl=6
Hello,
I see, but even making it?s value as 1, still doesn?t help ? :/
De: Masaru Oki [mailto:m-oki at stratosphere.co.jp]
Enviada em: quarta-feira, 26 de mar?o de 2014 23:18
Para: Fred Pedrisa
Cc: dev at dpdk.org
Assunto: Re: [dpdk-dev] RES: l2fwd high latency/delay
there is problem in l
2014-03-26 17:08, Olivier MATZ:
> 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 test
2014-02-04 16:54:
> Signed-off-by: Thomas Monjalon
Applied
--
Thomas
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
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: ic
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
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
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 usi
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 defa
> 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
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 pur
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
##
### Use
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 Wrigh
> > 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
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
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
Enviad
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) {
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.
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));
TUNABLE_S
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 Pedri
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 stratosphere.c
Hi, guys.
This variable is not working as intended for FreeBSD :(
It does not dettach nic_uio from the wanted ports :/
23 matches
Mail list logo
