> >> We will not have few more scheduler/queue implementations. We have to > >> consolidate the schedulers if that happens. The previous 3 schedulers > >> did not need #ifdefs in other modules as they did not change the queue > >> implementation. All of them use the same queue implementation. > > > > > > Then either the new one should use the same queue implementation or else > we > > should generalize this into a pluggable framework like the other > scheduler > > APIs. > > The existing queue implementation uses linked list. Many benefits are > due to using array to implement the queue. > We have seen the performance drops due to using function calls, moving > to function pointers would drop the performance even further.
Function inlining is most effective for short functions that are called often (like odp_packet_len()). For more complex functions, inlining or usage of functions pointer, does not have such large relative effect. E.g. if inlining saves 7 cycles, it can be >2x improvement for short function, but only couple percent for a complex function like schedule. When you add application code into the calculation, e.g. the 7 cycle save for each schedule() call is not very significant. When the function pointer based schedule interface was introduced e.g. l2fwd performance drop was negligible. The steps are: * first, clean integration * then, optimization if needed (without breaking modularity) -Petri
