Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
example/generator/odp_generator.c
line 200
@@ -784,10 +811,33 @@ static void print_pkts(int thr, thread_args_t *thr_args,
unsigned i;
size_t offset;
char msg[1024];
+ interface_t *itfs, *itf;
+
+ itfs = thr_args->rx.ifs;
for (i = 0; i < len; ++i) {
pkt = pkt_tbl[i];
+ itf = &itfs[odp_pktio_index(odp_packet_input(pkt))];
+
+ if (odp_packet_has_ipv4(pkt)) {
+ if (itf->config.pktin.bit.ipv4_chksum) {
+ if (odp_packet_has_l3_error(pkt))
+ printf("HW detected L3 error\n");
+ }
+ }
+
+ if (odp_packet_has_udp(pkt)) {
+ if (itf->config.pktin.bit.udp_chksum) {
+ if (odp_packet_has_l4_error(pkt))
+ printf("HW detected L4 error\n");
+ }
+ }
+
+ /* Drop packets with errors */
+ if (odp_unlikely(odp_packet_has_error(pkt)))
Comment:
Checksum errors will result in `odp_packet_has_error()` being set as well, so
these checks can be done only if the summary packet error predicate is set,
avoiding unnecessary checks for known good packets.
> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Might be good to have options for controlling the queue sync type here as
> `ODP_SCHED_SYNC_PARALLEL` should result in highest throughput, and
> `ODP_SCHED_SYNC_ORDERED` would be useful in testing performance of scheduler
> implementations (in theory should be better than `ODP_SCHED_SYNC_ATOMIC`).
>
> Something to explore in another PR
>> muvarov wrote
>> ok
>>> muvarov wrote
>>> and why odp_pktin_recv_tmo() and not odp_pktin_recv() ?
>>>> muvarov wrote
>>>> why not ODP_PKTIN_WAIT?
>>>>> muvarov wrote
>>>>> not all events are packets.
>>>>>> muvarov wrote
>>>>>> ```
>>>>>> * @return Next highest priority event
>>>>>> * @retval ODP_EVENT_INVALID on timeout and no events available
>>>>>> ```
>>>>>>> muvarov wrote
>>>>>>> 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_r158191188
updated_at 2017-12-21 03:50:22
