bogdanPricope 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:
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_r157140445
updated_at 2017-12-15 12:26:54
