Hi,
Would it solve your issue if we create queues with
ODP_SCHED_GROUP_DEFAULT consisting of cores which handle only the data
path traffic so that the traffic only gets dispatched to the data path
handling cores.
Is there any issue in handling the schedule queues coz running the
program on data path cores seems to be a simpler fix.
Regards,
Bala
On 03/02/15 6:37 pm, Radu-Andrei Bulie wrote:
As I said in my comment we could use two approaches.(poll or data path thread).
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:[email protected]]
Sent: Tuesday, February 03, 2015 2:59 PM
To: Bulie Radu-Andrei-B37577
Cc: [email protected]
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 <[email protected]> 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
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
