> From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias@nokia.com]
> Sent: Wednesday, September 5, 2018 8:49 AM
> To: Van Haaren, Harry
> Cc: Jerin Jacob ; dev@dpdk.org
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
>
>
> >>
> >&
>>
>> I'm not sure I understand the issue here.
>> Is anybody suggesting to make unlink() blocking?
>>
>> For certain PMDs, perhaps it must be a synchronous handled unlink().
>> For other PMDs (eg event/sw) there are multiple threads involved,
>> so it must be async. Hence, APIs should be async
-Original Message-
> Date: Fri, 10 Aug 2018 16:55:31 +
> From: "Van Haaren, Harry"
> To: Jerin Jacob , "Elo, Matias (Nokia -
> FI/Espoo)"
> CC: "dev@dpdk.org"
> Subject: RE: [dpdk-dev] eventdev: method for finding out unlink sta
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Friday, August 10, 2018 3:52 PM
> To: Elo, Matias (Nokia - FI/Espoo)
> Cc: Van Haaren, Harry ; dev@dpdk.org
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
>
> -Original Messa
-Original Message-
> Date: Fri, 10 Aug 2018 14:24:02 +
> From: "Elo, Matias (Nokia - FI/Espoo)"
> To: Jerin Jacob
> CC: "Van Haaren, Harry" , "dev@dpdk.org"
>
> Subject: Re: [dpdk-dev] eventdev: method for finding out
>
> # Other than that, I am still not able to understand, why not
> application wait until rte_event_port_unlink() returns.
Making rte_event_port_unlink() blocking would be troublesome if one doesn’t care
about unlink completion. E.g. doing dynamic load balancing.
>
> # What in real word use c
-Original Message-
> Date: Thu, 9 Aug 2018 13:14:40 +
> From: "Van Haaren, Harry"
> To: "Elo, Matias (Nokia - FI/Espoo)"
> CC: "dev@dpdk.org" , Jerin Jacob
>
> Subject: RE: [dpdk-dev] eventdev: method for finding out unlink s
> From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias@nokia.com]
> Sent: Wednesday, August 8, 2018 11:05 AM
> To: Van Haaren, Harry
> Cc: dev@dpdk.org; Jerin Jacob
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
>
>
> >>>>>&g
>>>
>>> I think the end result we're hoping for is something like pseudo code
>>> below,
>>> (keep in mind that the event/sw has a service-core thread running it,
>>> so no
>>> application code there):
>>>
>>> int worker_poll = 1;
>>>
>>> worker() {
>>
>>
>> I think the end result we're hoping for is something like pseudo code
>> below,
>> (keep in mind that the event/sw has a service-core thread running it, so
>> no
>> application code there):
>>
>> int worker_poll = 1;
>>
>> worker() {
>> while
-Original Message-
> Date: Tue, 31 Jul 2018 08:09:05 +
> From: "Elo, Matias (Nokia - FI/Espoo)"
> To: Jerin Jacob
> CC: "Van Haaren, Harry" , "dev@dpdk.org"
>
> Subject: Re: [dpdk-dev] eventdev: method for finding out
I think the end result we're hoping for is something like pseudo code
below,
(keep in mind that the event/sw has a service-core thread running it, so no
application code there):
int worker_poll = 1;
worker() {
while(worker_poll) {
// e
On 30 Jul 16:06, Jerin Jacob wrote:
> -Original Message-
> > Date: Mon, 30 Jul 2018 09:38:01 +
> > From: "Van Haaren, Harry"
> > To: Jerin Jacob , "Elo, Matias (Nokia -
> > FI/Espoo)"
> > CC: "dev@dpdk.org"
> > S
-Original Message-
> Date: Mon, 30 Jul 2018 13:36:35 +
> From: "Elo, Matias (Nokia - FI/Espoo)"
> To: Jerin Jacob
> CC: "Van Haaren, Harry" , "dev@dpdk.org"
>
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
&g
>> For this "runtime scale down" use-case the missing information is being
>> able to identify when an unlink is complete. After that (and ensuring the
>> port buffer is empty) the application can be guaranteed that there are no
>> more events going to be sent to that port, and the application ca
-Original Message-
> Date: Mon, 30 Jul 2018 09:38:01 +
> From: "Van Haaren, Harry"
> To: Jerin Jacob , "Elo, Matias (Nokia -
> FI/Espoo)"
> CC: "dev@dpdk.org"
> Subject: RE: [dpdk-dev] eventdev: method for finding out unlink sta
> I don't think that the eventdev API requires 1:1 Lcore / Port mapping, so
> really a
> PMD should be able to handle any thread calling any port.
>
> The event/sw PMD allows any thread to call dequeue/enqueue any port,
> so long as it is not being accessed by another thread.
>
>
A given
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Monday, July 30, 2018 10:29 AM
> To: Elo, Matias (Nokia - FI/Espoo)
> Cc: dev@dpdk.org; Van Haaren, Harry
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
>
> -Original Message--
-Original Message-
> Date: Mon, 30 Jul 2018 09:17:47 +
> From: "Elo, Matias (Nokia - FI/Espoo)"
> To: Jerin Jacob
> CC: "dev@dpdk.org" , "Van Haaren, Harry"
>
> Subject: Re: [dpdk-dev] eventdev: method for finding out
>>
>> In bug report https://bugs.dpdk.org/show_bug.cgi?id=60 we have been
>> discussing
>> issues related to events ending up in wrong ports after calling
>> rte_event_port_unlink(). In addition of finding few bugs we have identified a
>> need for a new API call (or documentation extension) for
-Original Message-
> Date: Mon, 30 Jul 2018 06:39:45 +
> From: "Elo, Matias (Nokia - FI/Espoo)"
> To: "dev@dpdk.org"
> CC: "Van Haaren, Harry"
> Subject: [dpdk-dev] eventdev: method for finding out unlink status
> x-mailer: Apple Mail (2.3445.9.1)
>
>
> Hi,
>
> In bug report https
21 matches
Mail list logo