Hi,
> > There is also a second thing: how to disable checksum calculation
> > per-packet?
> We've talked about doing this but currently have no APIs for exposing this
> capability. Do you have a use case in mind?
The use cases include many UDP based tunneling protocols that want to disable
checksumming to save processing capacity both locally and in the other end.
These include VxLAN, IPsec-over-UDP, MPLS-over-UDP, GTP.
For instance, the VxLAN RFC says that the UDP checksum SHOULD be set to zero,
but currently there is no reliable way for an ODP application to do so if
the checksum offload feature is enabled in the output interface.
The pktin side could also benefit from checksum API changes. It seems that
now the ODP application must assume that L4 checksum was calculated if the
feature was enabled in the pktin config and if the received packet was UDP,
TCP or SCTP and if the packet was not a fragment. Per-packet checksum flags
could be more robust and convenient.
Janne
> -----Original Message-----
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill
> Fischofer
> Sent: Wednesday, October 19, 2016 6:25 PM
> To: Maciej Czekaj <maciej.cze...@caviumnetworks.com>
> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] clarification of pktout checksum offload feature
>
> Hi Maciej, sorry for the delay in getting a response to you on this. See
> inline.
>
> On Thu, Oct 13, 2016 at 6:33 AM, Maciej Czekaj <
> maciej.cze...@caviumnetworks.com> wrote:
>
> >
> > Guys,
> >
> > I was going to implement checksum offload for OFP project based on Monarch
> > checksum offload capability and I found out that there is no example for
> > using that API. Also, documentation seams to leave some room for various
> > interpretations, so I would like to clarify that and post a patch to
> > documentation, too.
> >
> >
> > This is an exempt from pktio.h from Monarch LTS:
> >
> >
> > /**
> > * Packet output configuration options bit field
> > *
> > * Packet output configuration options listed in a bit field structure.
> > Packet
> > * output checksum insertion may be enabled or disabled. When it is
> > enabled,
> > * implementation will calculate and insert checksum into every outgoing
> > packet
> > * by default. Application may use a packet metadata flag to disable
> > checksum
> > * insertion per packet bases. For correct operation, packet metadata must
> > * provide valid offsets for the appropriate protocols. For example, UDP
> > * checksum calculation needs both L3 and L4 offsets (to access IP and UDP
> > * headers). When application (e.g. a switch) does not modify L3/L4 data
> > and
> > * thus checksum does not need to be updated, output checksum insertion
> > should
> > * be disabled for optimal performance.
> >
> >
> >
> > From my contact with varoius NICs, including Octeon PKO & VNIC from
> > ThunderX, offloading H/W needs at least:
> >
> > For L4 offload:
> > L4 packet type: TCP/UDP/SCTP
> > L4 header offset
> > L3 header offset
> > L3 type may or may not be required but it is good to define it for
> > consistency
> >
> > For L3 checksum:
> > L3 packet type: IPv4
> > L3 header offset
> >
>
> Yes, this info will be set by the ODP classifier. If you're constructing
> packets "by hand" then these fields should be set with appropriate
> odp_packet_xxx_set() calls.
>
>
> >
> > There is also a second thing: how to disable checksum calculation
> > per-packet?
> > If packet has no type in metadata, then obviously checksum will not be
> > computed. I think that would be the recommended method for now, even if ODP
> > community plans to extend odp_packet API in the future to cover that case.
> >
>
> We've talked about doing this but currently have no APIs for exposing this
> capability. Do you have a use case in mind?
>
>
> >
> > Maybe that is implicit that packet types should be set along header
> > offsets, but it is good to state that clearly and provide some usage
> > example, e.g. in examples/generator. I can send a patch for both doc and
> > generator but I would like to make sure we are on the same page.
> >
>
> Patches always welcome. :)
>
> Thanks.
>
>
> >
> >
> > Regards
> > Maciej
> >
> >
> >
> >
