Petri Savolainen(psavol) 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:
Actually, today's pktio capa is too permissive as all config options are
automatically capas. That should be changed to align this: pkt input checksums
have capas, output not. Application does not ask output checksum when not
needed. On input application does not have a change to filter packet checksum
checking before it sees the packet, but on output it can filter the checksum
generation.
> JannePeltonen wrote
> That is right, but there is no limitation in this API.
>
> This bit is just for tunnel mode dummy packets that cannot otherwise be sent.
> Transport mode dummy TFC packets are sent in the normal way: The input packet
> to an oubound IPsec operation is a well formed IP packet just like in the
> normal packet case, but the application just sets the protocol field of the
> IP header to 59. The ODP implementation needs the IP header to be there since
> that IP header is used (after some adjustments) in the resulting ESP/AH
> packet. This is different from tunnel mode where the outer IP header is
> generated based on the information in the SA.
>> JannePeltonen wrote
>> Two cases:
>> 1) Enabling TFC dummy packet generation for tunnel-mode SAs that have been
>> configured to copy the fields from the inner header. This way the input
>> packet to the IPsec operation does not have to contain valid IP header for
>> the copying to work which would be difficult to specify for dummy packets
>> (e.g. how to tell if the inner packet is IPv4 or IPv6). The fields cannot
>> just be left to some default values in dummy packets because that could
>> allow one to distinguish the dummy packets from normal packets in the wire,
>> rendering TFC dummy packets useless.
>>
>> 2) Making the current API more complete (regardless of TFC support).
>> Currently it is possible to set those fields only to the same SA-specific
>> value or copy from the inner header, but not set the value depending on the
>> packet. I could imagine that for DSCP there could be real use cases where
>> the DSCP cannot just be copied (e.g. since if the inner and outer packet
>> belong to different QoS domains with different DSCP interpretation) but the
>> DSCP cannot also be the same for all packets of an SA (although It would be
>> better to you separate SAs in that case).
>>> JannePeltonen wrote
>>> 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_r162563792
updated_at 2018-01-19 08:46:38
