muvarov replied on github web page:
example/generator/odp_generator.c
@@ -517,10 +520,13 @@ static int create_pktio(const char *dev, odp_pool_t pool,
odp_pktio_param_t pktio_param;
odp_pktin_queue_param_t pktin_param;
odp_pktout_queue_param_t pktout_param;
- odp_pktio_op_mode_t pktout_mode;
+ odp_pktio_op_mode_t pktout_mode, pktin_mode;
odp_pktio_param_init(&pktio_param);
- pktio_param.in_mode = ODP_PKTIN_MODE_SCHED;
+ pktio_param.in_mode = num_rx_queues ? ODP_PKTIN_MODE_DIRECT :
+ ODP_PKTIN_MODE_DISABLED;
+ pktio_param.out_mode = num_tx_queues ? ODP_PKTOUT_MODE_DIRECT :
+ ODP_PKTOUT_MODE_DISABLED;
Comment:
just separate rx function for scheduler and on thread start you just select
scheduler or direct.
> bogdanPricope wrote
> This will complicate this already over-complicated code: we may need to
> decide between ultimate performance and feature richness.
>> bogdanPricope wrote
>> No - we need to print csum errors first.
>> This part was significantly changed in api-next (csum checks use different/
>> new API) and it makes no sense to optimize it for the old (master) code.
>> After integration in api-next, this part will be reworked to use less
>> parser flags (reduce parsing level).
>> For example, removing L4 parsing and locating interface is bringing an extra
>> 1 mpps.
>>> bogdanPricope wrote
>>> '-r' may work.
>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>> Having an option to use direct mode seems reasonable, but shouldn't we
>>>> retain schedule mode (perhaps as a command line switch)? This would
>>>> provide an easy means of testing scheduler efficiency as it is tuned. At
>>>> least in some environments we'd like schedule mode to show better
>>>> performance than direct.
>>>>> muvarov wrote
>>>>> that has to be the first check.
>>>>>> muvarov wrote
>>>>>> -r ?
https://github.com/Linaro/odp/pull/343#discussion_r157171686
updated_at 2017-12-15 12:26:54
