Bill Fischofer(Bill-Fischofer-Linaro) 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:
OK
> Balasubramanian Manoharan(bala-manoharan) wrote:
> Does this mean the application will create a TFC dummy packet?
> I thought we decided that the application will only provide the length and
> dummy packet flag and implementation will generate a dummy packet.
>
>> Balasubramanian Manoharan(bala-manoharan) wrote:
>> Does this mean we have to set L3 offset for Dummy packets? Is there any
>> use-case for this scenario.
>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>> "Confidential information" How does the implementation guarantee this? Do
>>> we really need this in the spec?
>>>> Petri Savolainen(psavol) wrote:
>>>> 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_r163061457
updated_at 2018-01-22 20:39:07
