Petri Savolainen(psavol) replied on github web page:
include/odp/api/spec/ipsec.h
line 47
@@ -382,6 +382,44 @@ typedef struct odp_ipsec_crypto_param_t {
} odp_ipsec_crypto_param_t;
+/** IPv4 header parameters */
+typedef struct odp_ipsec_ipv4_param_t {
+ /** IPv4 source address (NETWORK ENDIAN) */
+ void *src_addr;
+
+ /** IPv4 destination address (NETWORK ENDIAN) */
+ void *dst_addr;
+
+ /** IPv4 Differentiated Services Code Point */
+ uint8_t dscp;
+
+ /** IPv4 Don't Fragment bit */
+ uint8_t df;
+
+ /** IPv4 Time To Live */
+ uint8_t ttl;
+
+} odp_ipsec_ipv4_param_t;
+
+/** IPv6 header parameters */
+typedef struct odp_ipsec_ipv6_param_t {
+ /** IPv6 source address (NETWORK ENDIAN) */
+ void *src_addr;
+
+ /** IPv6 destination address (NETWORK ENDIAN) */
+ void *dst_addr;
+
+ /** IPv6 Differentiated Services Code Point */
+ uint8_t dscp;
+
+ /** IPv6 flow label */
+ uint32_t flabel;
Comment:
yes it could. I try to remember that if v2 is needed.
> Petri Savolainen(psavol) wrote:
> 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_r162564224
updated_at 2018-01-19 08:48:49
