JannePeltonen replied on github web page:
include/odp/api/spec/ipsec.h
line 7
@@ -238,6 +238,11 @@ typedef struct odp_ipsec_capability_t {
*/
odp_support_t retain_header;
+ /**
+ * Inner packet checksum check offload support in inbound direction.
+ */
+ odp_proto_chksums_t chksums_in;
Comment:
Why? The rationale goes that if checksumming is requested in the outbound
direction the implementation can always calculate in in SW since that is what
the application would have to do otherwise. Inbound direction is different
since the need for L4 checksum checking (i.e. is the packet destined to this
system of just forwarded) is not yet known at the time of reception (so if an
implementation sets the inbound capability, it should mean that it can do
checksumming clearly more efficiently than pure SW).
> Dmitry Eremin-Solenikov(lumag) wrote:
> Hmm. I think RFC 4303 does not limit TFC dummy packets to tunnel mode. One
> can generate them in transport mode.
>> Dmitry Eremin-Solenikov(lumag) wrote:
>> What is the use case for these options?
>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> There is one indeed.
>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>> Is there no need for a corresponding `chksums_out` capability?
>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>> I assume this is referring to the `odp_packet_has_ipv4()` and
>>>>> `odp_packet_has_ipv6()` accessor functions? Since these bits are only
>>>>> accessible via these functions, this forces applications to play a
>>>>> guessing game with them and their L4 counterparts. Might it be better to
>>>>> consider having `odp_packet_l3_proto()` and `odp_packet_l4_proto()`
>>>>> functions?
>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>> Can `flabel` be placed after `dst_addr`? This would avoid the pad bytes
>>>>>> that would otherwise be inserted between `dspc` and `flabel`.
https://github.com/Linaro/odp/pull/403#discussion_r162550578
updated_at 2018-01-19 07:16:03
