2016-03-24 14:00, De Lara Guarch, Pablo:
> Hi,
>
> I just sent an alternative patch to solve the issue, without requiring
> #ifdefs.
> Could you take a look at it and check that works for you?
Please Dhananjaya Eadala,
Could you confirm the bug is fixed with this patch:
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ??
> Sent: Tuesday, March 15, 2016 1:03 AM
> To: Dhananjaya Eadala
> Cc: Richardson, Bruce; De Lara Guarch, Pablo; Qiu, Michael; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] hash: f
[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-
> process environment
>
> Hi,
>
> Pablo, Sergio, please could you help with this issue?
I agree this is not the best way to fix this. I will try to have a fix without
having to use ifdefs.
Thanks,
Pablo
>
>
Hi,
Pablo, Sergio, please could you help with this issue?
2016-03-13 22:16, Dhana Eadala:
> We found a problem in dpdk-2.2 using under multi-process environment.
> Here is the brief description how we are using the dpdk:
>
> We have two processes proc1, proc2 using dpdk. These proc1 and proc2
Thanks so much for your patch! Your patch exactly solves my bug. :)
At 2016-03-15 08:57:29, "Dhananjaya Eadala" wrote:
Hi
I looked at your info from gdb and source code.
Hi
I looked at your info from gdb and source code.
From source code, rte_hash_lookup_with_hash /
__rte_hash_lookup_with_hash() function doesn't invoke rte_hash_reset()
function.
It may be possible that rte_hash_cmp_eq function pointer from one
process is matching to address of rte_hash_reset
BTW, the following is my backtrace when the system crashes.
Program received signal SIGSEGV, Segmentation fault.
0x004883ab in rte_hash_reset (h=0x0)
at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:444
444while (rte_ring_dequeue(h->free_slots, ) ==
I met a problem which I used the DPDK hash table for multi processes. One
started as primary process and the other as secondary process.
I based on the client and server multiprocess example. My aim is that server
creates a hash table, then share it to the client. The client will read and
We found a problem in dpdk-2.2 using under multi-process environment.
Here is the brief description how we are using the dpdk:
We have two processes proc1, proc2 using dpdk. These proc1 and proc2 are
two different compiled binaries.
proc1 is started as primary process and proc2 as secondary
Hi Michael
If you agree on the #ifdef protection I explained in my previous mail, I
will re-submit the patch with refactoring the the commit log with less than
80 characters per line.
Thanks
Dhana
On Thu, Mar 3, 2016 at 8:00 PM, Dhananjaya Reddy Eadala
wrote:
> Hi Michael
>
> Please see my
Hi Michael
Please see my answers to your comments here.
1. Sure, I will refactor the commit log to restrict not more than 80
characters.
2. Not sure how we can ifdef at the location you mentioned. Can you please
elaborate more on this.
We already have similar ifdef protection to what you
On 3/3/2016 11:36 AM, Dhana Eadala wrote:
> We found a problem in dpdk-2.2 using under multi-process environment.
> Here is the brief description how we are using the dpdk:
>
> We have two processes proc1, proc2 using dpdk. These proc1 and proc2 are two
> different compiled binaries.
> proc1 is
We found a problem in dpdk-2.2 using under multi-process environment.
Here is the brief description how we are using the dpdk:
We have two processes proc1, proc2 using dpdk. These proc1 and proc2 are two
different compiled binaries.
proc1 is started as primary process and proc2 as secondary
13 matches
Mail list logo
