Petri Savolainen(psavol) replied on github web page:
include/odp/api/spec/ipsec.h
line 144
@@ -983,9 +983,55 @@ typedef struct odp_ipsec_op_flag_t {
* These may be used to override some SA level options
*/
typedef struct odp_ipsec_out_opt_t {
+ /** Union of all flag bits */
+ union {
+ /** Option flags. Set flag for those options that are
+ * used, all other options are ignored. */
+ struct {
+ /** Use fragmentation mode option */
+ uint32_t frag_mode: 1;
+
+ /** Use IP parameters option */
+ uint32_t ip_param: 1;
+
+ /** Use TFC padding length option */
+ uint32_t tfc_pad: 1;
+
+ /** Tunnel mode TFC dummy packet. In tunnel mode, set
+ * this flag to create a TFC dummy packet. The flag
+ * indicates packet data (at L3 offset) does not
+ * contain an inner packet IP header. If SA is
+ * configured to copy IP header fields from inner
+ * packet, those fields must be passed with
+ * IP parameters option. */
+ uint32_t tfc_dummy: 1;
+ } flag;
+
+ /** All flag bits */
+ uint32_t all_flags;
+ };
+
/** Fragmentation mode */
odp_ipsec_frag_mode_t frag_mode;
+ /** Union of IP parameters */
+ union {
+ /** Override IPv4 parameters in outer header creation.
+ * IP addresses are ignored. */
+ odp_ipsec_ipv4_param_t ipv4;
+
+ /** Override IPv6 parameters in outer header creation.
+ * IP addresses are ignored. */
+ odp_ipsec_ipv6_param_t ipv6;
Comment:
3. Also regardless of TFC support. If inner packet is IPv4, but outer is IPv6
and e.g. flabel has been configured to be copied from inner to outer - there's
no flabel in inner packet to copy. So, application is able to use this option
to pass per packet IPv6 parameters when inner is IPv4, and vice versa.
> Petri Savolainen(psavol) wrote:
> Application needs to anyway check if packet is v4 or v6. Today it's checking
> that from first byte of the packet. With TFC tunnel mode, first byte is
> garbage that cannot be used any more. So, application uses these APIs instead
> in if - else if - else fashion. There's no more guessing than before.
>> Petri Savolainen(psavol) wrote:
>> 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_r162566880
updated_at 2018-01-19 09:02:38
