Sounds like the API spec could be tightened up a bit to reflect that. I've posted PR #247[1] to add that clarification.
--- [1] https://github.com/Linaro/odp/pull/247 On Fri, Oct 20, 2017 at 1:19 AM, Bogdan Pricope <bogdan.pric...@linaro.org> wrote: > Hi, > > odp_pktio_config() works as you said: > > https://github.com/Linaro/odp/blob/api-next/platform/linux- > generic/odp_packet_io.c > > > int odp_pktio_config(odp_pktio_t hdl, const odp_pktio_config_t *config) > { > ............ > > /* Check config for invalid values */ > if (config->pktin.all_bits & ~capa.config.pktin.all_bits) { > ODP_ERR("Unsupported input configuration option\n"); > return -1; > } > if (config->pktout.all_bits & ~capa.config.pktout.all_bits) { > ODP_ERR("Unsupported output configuration option\n"); > return -1; > } > ............. > } > > /Bogdan > > On 20 October 2017 at 03:54, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > > > > > > On Thu, Oct 19, 2017 at 8:00 AM, Bogdan Pricope < > bogdan.pric...@linaro.org> > > wrote: > >> > >> Hi Petri and Janne, > >> > >> On APIs: > >> > >> void odp_packet_l3_chksum_insert(odp_packet_t pkt, int l3); > >> void odp_packet_l4_chksum_insert(odp_packet_t pkt, int l4); > >> > >> What is the expected behavior is checksum is requested but interface > >> does not support it? > >> > >> a) best effort - do if you can (do nothing) > >> b) drop packet > >> c) ?? > > > > > > The spec is pretty clear on this point: > > > > * Calling this function is always allowed but the checksum will not be > > * inserted if the packet is output through a pktio that does not have > > * the relevant pktout chksum bit set in the pktio capability. > > > > If the pktio doesn't have checksumming capability (as reported by > > odp_pktio_capability()) then these bits will not be set. The real > ambiguity > > in the spec is what happens if odp_pktio_capability() reports they are > not > > available but odp_pktio_config() attempts to set them. They should > either be > > ignored in that case or else the odp_pktio_config() should fail. The > latter > > makes more sense since presumably if the application tried to set other > > config options that weren't supported (e.g., loopback mode) that > certainly > > should not be silently ignored if it is not supported. > > > >> > >> > >> /Bogdan > > > > >