[dpdk-dev] Using DPDK in a multiprocess environment

2014-04-08 Thread elevran
Jeff, Thanks for the quick reply. I'll see if calling eal_init earlier resolves the problem I'm seeing. I'm not sure this will resolve the issue if shared objects are loaded before main() starts... I understand the rationale for having the same mbuf addresses across processes. And indeed they're

[dpdk-dev] Using DPDK in a multiprocess environment

2014-04-08 Thread Etai Lev Ran
Hi, I'd like to split DPDK application functionality into a setup (primary) process and business logic (secondary) processes. The secondary processes access the hardware queues directly (exclusive queue per process) and not through software rings. I'm running into an initialization problem:

[dpdk-dev] Using DPDK in a multiprocess environment

2014-04-08 Thread Rogers, Gerald
Etai, If this doesn?t work, then you will need to change the virtual address range that is used by DPDK. By default this is set dynamically, however; with DPDK 1.6you can change it to any region in the virtual address space you want. The problem you have is what you stated, the secondary process

[dpdk-dev] Using DPDK in a multiprocess environment

2014-04-08 Thread Shaw, Jeffrey B
Have you tried calling "rte_eal_init()" closer to the beginning of the program in your secondary process (i.e. the first thing in main())? The same mmap address is required. The reason is simple, if process A thinks the virtual address of an mbuf is 123, and process B thinks the virtual address

[dpdk-dev] [PATCH v3 2/2] igb: release software locked semaphores on initialization

2014-04-08 Thread Didier Pallard
It may happen that DPDK application gets killed while having acquired locks on the ethernet hardware, causing these locks to be never released. On next restart of the application, DPDK skip those ports because it can not acquire the lock, this may cause some ports (or even complete board if SMBI is

[dpdk-dev] [PATCH v3 1/2] ixgbe: release software locked semaphores on initialization

2014-04-08 Thread Didier Pallard
It may happen that DPDK application gets killed while having acquired locks on the ethernet hardware, causing these locks to be never released. On next restart of the application, DPDK skip those ports because it can not acquire the lock, this may cause some ports (or even complete board if SMBI is

[dpdk-dev] bypass event for reboot

2014-04-08 Thread Sharath
Hi Konstantin, could you please comment on this. thanks, Sharath On Fri, Apr 4, 2014 at 6:12 PM, Sharath wrote: > Hi! > > I have been able to use the below API to set the bypass event on power off > and power on > > * int rte_eth_dev_bypass_event_store (uint8_t port, uint32_t event, > uint32_t