> From: Richardson, Bruce
> > Agreed, however hiding it totally removes the flexibility of waiting for a
> > primary
> > that is starting with --file-prefix (aka: in a non-default location).
> > Imposing
> > a limit on only monitoring primary procs in the default location seems
> > wrong.
>
>
> From: Qiu, Michael
> > Whatever work the secondary was performing (in its own address space)
> > won't be directly changed by the primary being killed, because the
> > shared config and hugepages stay (EAL "cleans up" when the primary
> > is re-launched, not on quit).
>
> OK, when primary quit
On Mon, Jan 25, 2016 at 11:44:59AM +, Van Haaren, Harry wrote:
> > From: Richardson, Bruce
> > The details of what the config file is should largely be hidden from the
> > user
> > IMHO.
>
> Agreed, however hiding it totally removes the flexibility of waiting for a
> primary
> that is
On 1/26/2016 5:04 PM, Van Haaren, Harry wrote:
>> From: Qiu, Michael
>> On 1/25/2016 7:51 PM, Van Haaren, Harry wrote:
>>> Not really, the secondary process will need some CPU,
>>> however it can sleep so it doesn't have to use 100% of it.
>>> It shouldn't be run on a core that is used by the
> From: Qiu, Michael
> On 1/25/2016 7:51 PM, Van Haaren, Harry wrote:
> > Not really, the secondary process will need some CPU,
> > however it can sleep so it doesn't have to use 100% of it.
> > It shouldn't be run on a core that is used by the primary
> > for packet-forwarding though - that will
On 1/25/2016 7:51 PM, Van Haaren, Harry wrote:
>> From: Qiu, Michael
>> Subject: Re: [dpdk-dev] [PATCH] eal: add function to check if primary proc
>> alive
>>
>> So secondary will waste a whole lcore to do such polling?
> Not really, the secondary process wil
> From: Qiu, Michael
> Subject: Re: [dpdk-dev] [PATCH] eal: add function to check if primary proc
> alive
>
> So secondary will waste a whole lcore to do such polling?
Not really, the secondary process will need some CPU,
however it can sleep so it doesn't have to use 100% of i
> From: Richardson, Bruce
> The details of what the config file is should largely be hidden from the user
> IMHO.
Agreed, however hiding it totally removes the flexibility of waiting for a
primary
that is starting with --file-prefix (aka: in a non-default location). Imposing
a limit on only
On 1/20/2016 9:26 PM, Harry van Haaren wrote:
> This patch adds a new function to the EAL API:
> int rte_eal_primary_proc_alive(const char *path);
>
> The function indicates if a primary process is alive right now.
> This functionality is implemented by testing for a write-
> lock on the config
; Cc: dev at dpdk.org
>>> Subject: Re: [dpdk-dev] [PATCH] eal: add function to check if primary proc
>>> alive
>>>
>>> As we could start up many primaries, how does your secondary process
>>> work with them?
>> When a primary process initializes,
On Thu, Jan 21, 2016 at 09:02:41AM +, Van Haaren, Harry wrote:
> > From: Qiu, Michael
> > Sent: Thursday, January 21, 2016 6:14 AM
> > To: Van Haaren, Harry ; david.marchand at
> > 6wind.com
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] eal: a
> From: Qiu, Michael
> Sent: Thursday, January 21, 2016 6:14 AM
> To: Van Haaren, Harry ; david.marchand at
> 6wind.com
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: add function to check if primary proc
> alive
>
> As we could start up many primari
On 1/20/2016 9:26 PM, Harry van Haaren wrote:
> This patch adds a new function to the EAL API:
> int rte_eal_primary_proc_alive(const char *path);
>
> The function indicates if a primary process is alive right now.
> This functionality is implemented by testing for a write-
> lock on the config
On 1/20/16 10:14 PM, Qiu, Michael wrote:
> As we could start up many primaries, how does your secondary process
> work with them?
I just worked on this tonight myself. When doing > 1 primary (for
example pktgen and app), I had to specify:
--no-shconf
--file-prefix pktgen
--file-prefix app
Or
This patch adds a new function to the EAL API:
int rte_eal_primary_proc_alive(const char *path);
The function indicates if a primary process is alive right now.
This functionality is implemented by testing for a write-
lock on the config file, and the function tests for a lock.
The use case for
15 matches
Mail list logo