JannePeltonen 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:
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_r162551898
updated_at 2018-01-19 07:26:38
