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:[email protected]] Sent: Tuesday, February 03, 2015 3:29 PM To: Bulie Radu-Andrei-B37577 Cc: [email protected] Subject: Re: [lng-odp] classification tests scheduled queues On Tue, Feb 03, 2015 at 01:07:15PM +0000, 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:[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
