> On 24 May 2017, at 11:32, Bogdan Pricope <bogdan.pric...@linaro.org> wrote:
>
> Hi Matias,
>
> Using ptypes reported by dpdk in parser was intended for another patch
> (next work after csum).
>
Good, so we are on the same page. When implementing packet parsing you have to
move/reimplement this checksum code anyway, so it makes more sense to implement
both of them in the same patch / patch set.
> I guess your test is a degradation test (due to new ifs) and you did
> not enabled csum offloads/ set flags on packets.
Yep, just standard l2fwd test without any offload flags.
>
> What will be interesting to see:
> - in a generation or termination test (UDP), what will be
> degradation/gain with csum offload enabled
> - how degradation/gain is changing with bigger packets (256 bytes vs 64 bytes)
That would definitely be more interesting. I tried quickly enabling
'ipv4_chksum'
and 'udp_chksum' flags on odp_l2fwd and the performance degradation was minimal
(~0.2%).
While testing this I noticed a small problem in the code:
> + ptype_cnt = rte_eth_dev_get_supported_ptypes(pkt_dpdk->port_id,
> +
> ptype_mask, ptypes, ptype_cnt);
> + for (i = 0; i < ptype_cnt; i++)
> + switch (ptypes[i]) {
> + case RTE_PTYPE_L3_IPV4:
> + ptype_l3_ipv4 = 1;
> + break;
> + case RTE_PTYPE_L4_TCP:
> + ptype_l4_tcp = 1;
> + break;
> + case RTE_PTYPE_L4_UDP:
> + ptype_l4_udp = 1;
> + break;
> + }
> + }
This doesn't work alone in all cases. For example Fortville NIC uses
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN but not RTE_PTYPE_L3_IPV4.
-Matias
