Re: [lng-odp] classification tests scheduled queues
This is an option - to set the affinity -of the main thread to another
core(other than the first core) - that is a datapath core.
But that means to update the cunnit common and set the affinity before the call
to odp_init_local. The calling sequence will be
Something like this:
odph_linux_cpumask_default(cpumask, 0);
cpu = odp_cpumask_first(cpumask);
cpu = odp_cpumask_next(cpumask, cpu);
odp_cpumask_zero(cpumask);
odp_cpumask_set(cpumask, cpu);
...
if (0 != odp_init_local()) {
But I didn't look further to see if this will affect other validation tests
that use the cunnit_common.
As I said, according to your suggestion, from the classification tests
perspective this minimal change will fix the schedule approach.
Regards,
Radu
-Original Message-
From: Balasubramanian Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Wednesday, February 11, 2015 2:42 AM
To: Bulie Radu-Andrei-B37577
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] classification tests scheduled queues
On 10/02/15 11:28 pm, Balasubramanian Manoharan wrote:
On 10/02/15 5:37 pm, Radu-Andrei Bulie wrote:
Hi,
Regarding my comments, I want to know how it will be proceeded. Will
be there any patches that will update the current classification
tests to support the poll and updated scheduled queues version?
We will update the validation suite to test for both schedule and poll
based queues.
Regards,
Bala
Hi,
In case of schedule based queues can you set the core affinity on the
application to run only on data path cores.This should solve the issue which
you had described earlier in this mail.
Regards,
Bala
Regards,
Radu
-Original Message-
From: Bulie Radu-Andrei-B37577
Sent: Tuesday, February 03, 2015 3:59 PM
To: 'Jerin Jacob'
Cc: lng-odp@lists.linaro.org; 'ola.liljed...@linaro.org';
'Balasubramanian Manoharan'
Subject: RE: [lng-odp] classification tests scheduled queues
Hi,
I think it's a good approach. One could see the functional test
behavior using either poll or schedule on the classification path.
-Original Message-
From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
Sent: Tuesday, February 03, 2015 3:29 PM
To: Bulie Radu-Andrei-B37577
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] classification tests scheduled queues
On Tue, Feb 03, 2015 at 01:07:15PM +, Radu-Andrei Bulie wrote:
As I said in my comment we could use two approaches.(poll or data
path thread).
How about the scheme(#define IPSEC_POLL_QUEUES) followed in existing
example/ipsec to abstract polled vs schedule mode ?
The one you mentioned reflects the model of the reference applications.
Classification test itself, for the present moment, is a functional
test and does not target performance. So I don't see a major
difference in using poll or a data path thread.
Regards,
Radu
-Original Message-
From: Ola Liljedahl [mailto:ola.liljed...@linaro.org]
Sent: Tuesday, February 03, 2015 2:59 PM
To: Bulie Radu-Andrei-B37577
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] classification tests scheduled queues
Wouldn't it be better to modify the validation program to make sure
scheduling is always performed on a data path thread?
We want to promote usage of the scheduler, HW-accelerated
classification and scheduling are some of the differentiators of ODP.
On 3 February 2015 at 13:53, Radu-Andrei Bulie
radu.bu...@freescale.com wrote:
Hi,
I have a comment regarding the scheduling approach in the
classification validation tests (this also can be extended to other
tests which use the same pattern).
The schedule function should be called in context of a data path
thread that is bound to a known core (the same model as in pktio
application for instance). Otherwise
(as in the mentioned test) the main process (in this case the cunit
test) can be scheduled by Linux on any core – e.g core 0 – that is
not in the data path. In this situation no dequeue will occur,
because the scheduling does not take place on a data path thread
(unlike the case for pktio application where there is a cpu
dedicated to control path).
From the linux-generic perspective, there is no apparent issue in
using the schedule function in this context. But as it is given in
the reference application, the purpose of the scheduling is to
function on the data path and thus to provide the advantages given
by different SoCs acceleration implementations. (there will always
be a control core and some data path cores).
Thus, being in accordance with the reference applications from odp,
I suggest replacing the scheduled queues with poll queues or create
a separate thread which receives the packet, otherwise the test
will function only on linux generic implementation.
PS: I could send the patch (using poll queues approach) if we reach
a consensus.
Regards,
Radu
Re: [lng-odp] classification tests scheduled queues
On 10/02/15 5:37 pm, Radu-Andrei Bulie wrote: Hi, Regarding my comments, I want to know how it will be proceeded. Will be there any patches that will update the current classification tests to support the poll and updated scheduled queues version? We will update the validation suite to test for both schedule and poll based queues. Regards, Bala Regards, Radu -Original Message- From: Bulie Radu-Andrei-B37577 Sent: Tuesday, February 03, 2015 3:59 PM To: 'Jerin Jacob' Cc: lng-odp@lists.linaro.org; 'ola.liljed...@linaro.org'; 'Balasubramanian Manoharan' Subject: RE: [lng-odp] classification tests scheduled queues Hi, I think it's a good approach. One could see the functional test behavior using either poll or schedule on the classification path. -Original Message- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Tuesday, February 03, 2015 3:29 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues On Tue, Feb 03, 2015 at 01:07:15PM +, Radu-Andrei Bulie wrote: As I said in my comment we could use two approaches.(poll or data path thread). How about the scheme(#define IPSEC_POLL_QUEUES) followed in existing example/ipsec to abstract polled vs schedule mode ? The one you mentioned reflects the model of the reference applications. Classification test itself, for the present moment, is a functional test and does not target performance. So I don't see a major difference in using poll or a data path thread. Regards, Radu -Original Message- From: Ola Liljedahl [mailto:ola.liljed...@linaro.org] Sent: Tuesday, February 03, 2015 2:59 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues Wouldn't it be better to modify the validation program to make sure scheduling is always performed on a data path thread? We want to promote usage of the scheduler, HW-accelerated classification and scheduling are some of the differentiators of ODP. On 3 February 2015 at 13:53, Radu-Andrei Bulie radu.bu...@freescale.com wrote: Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core – e.g core 0 – that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] classification tests scheduled queues
Hi, Regarding my comments, I want to know how it will be proceeded. Will be there any patches that will update the current classification tests to support the poll and updated scheduled queues version? Regards, Radu -Original Message- From: Bulie Radu-Andrei-B37577 Sent: Tuesday, February 03, 2015 3:59 PM To: 'Jerin Jacob' Cc: lng-odp@lists.linaro.org; 'ola.liljed...@linaro.org'; 'Balasubramanian Manoharan' Subject: RE: [lng-odp] classification tests scheduled queues Hi, I think it's a good approach. One could see the functional test behavior using either poll or schedule on the classification path. -Original Message- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Tuesday, February 03, 2015 3:29 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues On Tue, Feb 03, 2015 at 01:07:15PM +, Radu-Andrei Bulie wrote: As I said in my comment we could use two approaches.(poll or data path thread). How about the scheme(#define IPSEC_POLL_QUEUES) followed in existing example/ipsec to abstract polled vs schedule mode ? The one you mentioned reflects the model of the reference applications. Classification test itself, for the present moment, is a functional test and does not target performance. So I don't see a major difference in using poll or a data path thread. Regards, Radu -Original Message- From: Ola Liljedahl [mailto:ola.liljed...@linaro.org] Sent: Tuesday, February 03, 2015 2:59 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues Wouldn't it be better to modify the validation program to make sure scheduling is always performed on a data path thread? We want to promote usage of the scheduler, HW-accelerated classification and scheduling are some of the differentiators of ODP. On 3 February 2015 at 13:53, Radu-Andrei Bulie radu.bu...@freescale.com wrote: Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core – e.g core 0 – that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] classification tests scheduled queues
On 10/02/15 11:28 pm, Balasubramanian Manoharan wrote: On 10/02/15 5:37 pm, Radu-Andrei Bulie wrote: Hi, Regarding my comments, I want to know how it will be proceeded. Will be there any patches that will update the current classification tests to support the poll and updated scheduled queues version? We will update the validation suite to test for both schedule and poll based queues. Regards, Bala Hi, In case of schedule based queues can you set the core affinity on the application to run only on data path cores.This should solve the issue which you had described earlier in this mail. Regards, Bala Regards, Radu -Original Message- From: Bulie Radu-Andrei-B37577 Sent: Tuesday, February 03, 2015 3:59 PM To: 'Jerin Jacob' Cc: lng-odp@lists.linaro.org; 'ola.liljed...@linaro.org'; 'Balasubramanian Manoharan' Subject: RE: [lng-odp] classification tests scheduled queues Hi, I think it's a good approach. One could see the functional test behavior using either poll or schedule on the classification path. -Original Message- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Tuesday, February 03, 2015 3:29 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues On Tue, Feb 03, 2015 at 01:07:15PM +, Radu-Andrei Bulie wrote: As I said in my comment we could use two approaches.(poll or data path thread). How about the scheme(#define IPSEC_POLL_QUEUES) followed in existing example/ipsec to abstract polled vs schedule mode ? The one you mentioned reflects the model of the reference applications. Classification test itself, for the present moment, is a functional test and does not target performance. So I don't see a major difference in using poll or a data path thread. Regards, Radu -Original Message- From: Ola Liljedahl [mailto:ola.liljed...@linaro.org] Sent: Tuesday, February 03, 2015 2:59 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues Wouldn't it be better to modify the validation program to make sure scheduling is always performed on a data path thread? We want to promote usage of the scheduler, HW-accelerated classification and scheduling are some of the differentiators of ODP. On 3 February 2015 at 13:53, Radu-Andrei Bulie radu.bu...@freescale.com wrote: Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core – e.g core 0 – that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] classification tests scheduled queues
Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core - e.g core 0 - that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] classification tests scheduled queues
Hi, I think it's a good approach. One could see the functional test behavior using either poll or schedule on the classification path. -Original Message- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Tuesday, February 03, 2015 3:29 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues On Tue, Feb 03, 2015 at 01:07:15PM +, Radu-Andrei Bulie wrote: As I said in my comment we could use two approaches.(poll or data path thread). How about the scheme(#define IPSEC_POLL_QUEUES) followed in existing example/ipsec to abstract polled vs schedule mode ? The one you mentioned reflects the model of the reference applications. Classification test itself, for the present moment, is a functional test and does not target performance. So I don't see a major difference in using poll or a data path thread. Regards, Radu -Original Message- From: Ola Liljedahl [mailto:ola.liljed...@linaro.org] Sent: Tuesday, February 03, 2015 2:59 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues Wouldn't it be better to modify the validation program to make sure scheduling is always performed on a data path thread? We want to promote usage of the scheduler, HW-accelerated classification and scheduling are some of the differentiators of ODP. On 3 February 2015 at 13:53, Radu-Andrei Bulie radu.bu...@freescale.com wrote: Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core – e.g core 0 – that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] classification tests scheduled queues
Wouldn't it be better to modify the validation program to make sure scheduling is always performed on a data path thread? We want to promote usage of the scheduler, HW-accelerated classification and scheduling are some of the differentiators of ODP. On 3 February 2015 at 13:53, Radu-Andrei Bulie radu.bu...@freescale.com wrote: Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core – e.g core 0 – that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] classification tests scheduled queues
On Tue, Feb 03, 2015 at 01:07:15PM +, Radu-Andrei Bulie wrote: As I said in my comment we could use two approaches.(poll or data path thread). How about the scheme(#define IPSEC_POLL_QUEUES) followed in existing example/ipsec to abstract polled vs schedule mode ? The one you mentioned reflects the model of the reference applications. Classification test itself, for the present moment, is a functional test and does not target performance. So I don't see a major difference in using poll or a data path thread. Regards, Radu -Original Message- From: Ola Liljedahl [mailto:ola.liljed...@linaro.org] Sent: Tuesday, February 03, 2015 2:59 PM To: Bulie Radu-Andrei-B37577 Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] classification tests scheduled queues Wouldn't it be better to modify the validation program to make sure scheduling is always performed on a data path thread? We want to promote usage of the scheduler, HW-accelerated classification and scheduling are some of the differentiators of ODP. On 3 February 2015 at 13:53, Radu-Andrei Bulie radu.bu...@freescale.com wrote: Hi, I have a comment regarding the scheduling approach in the classification validation tests (this also can be extended to other tests which use the same pattern). The schedule function should be called in context of a data path thread that is bound to a known core (the same model as in pktio application for instance). Otherwise (as in the mentioned test) the main process (in this case the cunit test) can be scheduled by Linux on any core – e.g core 0 – that is not in the data path. In this situation no dequeue will occur, because the scheduling does not take place on a data path thread (unlike the case for pktio application where there is a cpu dedicated to control path). From the linux-generic perspective, there is no apparent issue in using the schedule function in this context. But as it is given in the reference application, the purpose of the scheduling is to function on the data path and thus to provide the advantages given by different SoCs acceleration implementations. (there will always be a control core and some data path cores). Thus, being in accordance with the reference applications from odp, I suggest replacing the scheduled queues with poll queues or create a separate thread which receives the packet, otherwise the test will function only on linux generic implementation. PS: I could send the patch (using poll queues approach) if we reach a consensus. Regards, Radu ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
