Dmitry Eremin-Solenikov(lumag) replied on github web page:
include/odp/api/spec/ipsec.h
line 179
@@ -1226,12 +1226,23 @@ typedef struct odp_ipsec_status_t {
* e.g. RFC 4302 and 4303). Resulting packets are well formed, reconstructed
* original IP packets, with IPSEC headers removed and valid header field
values
* restored. The amount and content of packet data before the IP header is
- * undefined.
+ * undefined. Some amount of TFC padding may follow the IP packet payload,
+ * in which case packet length is larger than protocol headers indicate.
+ * TFC dummy packets have l3_type set to ODP_PROTO_L3_TYPE_NONE in tunnel mode
+ * or l4_type set to ODP_PROTO_L4_TYPE_NO_NEXT in transport mode. Dummy
+ * packets contain implementation specific amount of (dummy) data. Furthermore,
+ * inline IPSEC processing may drop dummy packets.
*
* Each successfully transformed packet has a valid value for these metadata
* regardless of the inner packet parse configuration
* (odp_ipsec_inbound_config_t):
- * - L3 offset: Offset to the first byte of the (outmost) IP header
+ * - l3_offset: Offset to the first byte of the original IP packet. The value
+ * is implementation specific for tunnel mode TFC dummy packets.
+ * - l3_type: Specifies if the original packet is IPv4 or IPv6. For tunnel
+ * mode TFC dummy packets set to ODP_PROTO_L3_TYPE_NONE.
Comment:
And here.
> Dmitry Eremin-Solenikov(lumag) wrote:
> It also should be NO_NEXT, shouldn't it?
>> Dmitry Eremin-Solenikov(lumag) wrote:
>> In fact I'm more biased towards
>> `odp_packet_get_l3_proto()`/`odp_packet_get_l4_proto()` functions.
>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> @lumag Would exposing he next header byte also be acceptable? That would
>>> similarly seem to be future-proof and would also avoid having to introduce
>>> an `odp_packet_has_dummy()` predicate function.
>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>> It seems @bala-manoharan and me would still prefer separate is_dummy flag.
>>>> We don't even have to limit it to TFC dummy packets, but might use it
>>>> later for all kinds of dummy packets.
>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>> Yes. Just to be clear even if the implementation know that its a dummy
>>>>> packet in Transport mode the application/implementation will have to
>>>>> parse the IP header to know the dummy packet and drop the packet.
>>>>>> JannePeltonen wrote
>>>>>> Transport mode dummy packets _are_ IP packets. The protocol field of the
>>>>>> IP header (which is constructed based on the IP header of the ESP
>>>>>> packet) is 59.
>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>> In tunnel mode not setting ipv4/v6 flag for dummy packet should be
>>>>>>> fine. But how do Dummy packets get handled in transport mode? coz if
>>>>>>> the implementation does inner packet parsing then transport mode dummy
>>>>>>> packet will have the valid ipv4/v6 flag set.
>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>> After discussion during the call: this needs to be rephrased to point
>>>>>>>> that TFC dummy packets can be truncated by an implementation. Maybe we
>>>>>>>> should not mention that "restructured data" is returned for TFC dummy
>>>>>>>> packet.
>>>>>>>>> JannePeltonen wrote
>>>>>>>>> On January 17 [email protected] wrote in the lng-odp list:
>>>>>>>>>
>>>>>>>>> "However, for the EIP96 - EIP197PP range of solutions our HW /is/
>>>>>>>>> capable of TFC padding insertion, we would just need to expose this
>>>>>>>>> through our driver and firmware. So API-wise you might want to
>>>>>>>>> support adding n bytes of TFC padding for outbound. "
>>>>>>>>>
>>>>>>>>> So apparently such HW exists. And even with pure SW solution, I do
>>>>>>>>> not see why buffer space would need to be allocated from application
>>>>>>>>> specific pools for the padding data.
>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>> I have mixed feelings towards this option. Allocating additional
>>>>>>>>>> buffer space from application-specific pools seems fragile to me.
>>>>>>>>>> Maybe we can leave this out for now till there is hardware which
>>>>>>>>>> actually supports generating additional TFC padding?
>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>> Limiting this option to tunnel mode only seems logical but not that
>>>>>>>>>>> effective for an application. Maybe we can allow using this option
>>>>>>>>>>> together with L3 header override to create transport mode dummy
>>>>>>>>>>> packets. Then it would be just easier to inject dummy packets in
>>>>>>>>>>> transport case.
>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>> @psavol I don't feel good about the 'if dummy flag is set, only
>>>>>>>>>>>> tfc_padding length defines the dummy packet length' proposal. Your
>>>>>>>>>>>> current phrase (`packet_len + tfc_padding` seems better to me).
>>>>>>>>>>>> @bala-manoharan if we do not provide a packet, how will
>>>>>>>>>>>> implementation allocate a packet for SYNC/ASYNC modes?
>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>> Also it should be documented that in INLINE mode hardware might
>>>>>>>>>>>>> drop dummy packets on its own, without reporting them to an
>>>>>>>>>>>>> application.
>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>> I'm actually thinking about adding special `is_dummy` flag here.
>>>>>>>>>>>>>> Transport mode TFC packets should have `has_ipv4`/`has_ipv6`
>>>>>>>>>>>>>> flag according to their headers. However having special flag
>>>>>>>>>>>>>> which can be checked by an application will allow one to drop
>>>>>>>>>>>>>> them without going to L3 headers.
>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>> This will cause troubles for NXP hardware, which does not
>>>>>>>>>>>>>>> output decrypted TFC packet, if I understand in right.
>>>>>>>>>>>>>>> @NikhilA-Linaro could you please comment?
>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>> We can also decide whether the application has to provide a
>>>>>>>>>>>>>>>> valid odp_packet_t handle when "tfc_dummy" flag is set.
>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>> About 2 vs. 3 level capability. Two levels should be enough
>>>>>>>>>>>>>>>>>> (no, yes). If there are 3 levels (no, yes in SW, yes in HW),
>>>>>>>>>>>>>>>>>> throughput would be optimized if application enables
>>>>>>>>>>>>>>>>>> checksumming only when it's done in HW. Application would
>>>>>>>>>>>>>>>>>> not request SW checksum for all packets, as it can filter
>>>>>>>>>>>>>>>>>> out those that actually need it (e.g. half of the packets)
>>>>>>>>>>>>>>>>>> and then do it in SW only for those.
>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>> I think the offset is already known (and possibly set into
>>>>>>>>>>>>>>>>>>> packet header) before implementation knows a packet is
>>>>>>>>>>>>>>>>>>> dummy, since that's part of decrypt operation (== start of
>>>>>>>>>>>>>>>>>>> cipher/clear text data). This spec allows L3 offset to be
>>>>>>>>>>>>>>>>>>> left at an implementation specific value, e.g. 0 if HW did
>>>>>>>>>>>>>>>>>>> drop the dummy content, e.g. 28 if HW does not recognize
>>>>>>>>>>>>>>>>>>> dummy packets (just another decrypted packet from HW point
>>>>>>>>>>>>>>>>>>> of view).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When dummy content is left there, application can see how
>>>>>>>>>>>>>>>>>>> much it is and the content. May be that helps in debugging
>>>>>>>>>>>>>>>>>>> dummy vs non-dummy packet, etc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Result of an IPSEC decrypt transformation is always the
>>>>>>>>>>>>>>>>>>> original packet (== what the sender did send). L3 offset
>>>>>>>>>>>>>>>>>>> points to the first byte of the original data. If dummy
>>>>>>>>>>>>>>>>>>> data was dropped, then there's no data.
>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>> This should be clear for implementers already from RFC,
>>>>>>>>>>>>>>>>>>>> but it's also here since it's easy to forget that data
>>>>>>>>>>>>>>>>>>>> cannot be sent out from any random address (e.g. end of an
>>>>>>>>>>>>>>>>>>>> buffer). Implementation must be sure about the memory
>>>>>>>>>>>>>>>>>>>> content (zeros, rand, counter) before including that as
>>>>>>>>>>>>>>>>>>>> padding.
>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>> We can also decide to write the spec differently. I.e. if
>>>>>>>>>>>>>>>>>>>>> dummy flag is set, only tfc_padding length defines the
>>>>>>>>>>>>>>>>>>>>> dummy packet length. May be it's better spec and as easy
>>>>>>>>>>>>>>>>>>>>> to implement than the one above.
>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>> It has been specified that number of bytes to IPsec
>>>>>>>>>>>>>>>>>>>>>> encrypt is always: packet_len - l3_offset + tfc_padding.
>>>>>>>>>>>>>>>>>>>>>> In all other cases (than TFC dummy in tunnel mode), L3
>>>>>>>>>>>>>>>>>>>>>> offset point to first byte of IP header. With dummy,
>>>>>>>>>>>>>>>>>>>>>> application is not required to form an IP header and
>>>>>>>>>>>>>>>>>>>>>> also packet data content is ignored. So, application can
>>>>>>>>>>>>>>>>>>>>>> e.g. set L3 offset = 0, packet_len = 0 and tfc_padding =
>>>>>>>>>>>>>>>>>>>>>> 512, OR L3 offset = 64, packet_len = 320, tfc_padding =
>>>>>>>>>>>>>>>>>>>>>> 256, OR L3 offset = 0, packet_len = 512, tfc_padding= 0.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> All those examples would end up implementation creating
>>>>>>>>>>>>>>>>>>>>>> a 512 byte dummy packet.
>>>>>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>>>>>> The implementation simply needs to ensure that it
>>>>>>>>>>>>>>>>>>>>>>> doesn't reuse application buffers, as they may contain
>>>>>>>>>>>>>>>>>>>>>>> residual confidential information. This can be done by
>>>>>>>>>>>>>>>>>>>>>>> inserting zeros or random bytes as the implementation
>>>>>>>>>>>>>>>>>>>>>>> chooses. Given the importance of security, it's
>>>>>>>>>>>>>>>>>>>>>>> appropriate to put this caveat in the spec as a
>>>>>>>>>>>>>>>>>>>>>>> reminder to implementations.
>>>>>>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>>>>>>> OK
>>>>>>>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Please do. While padding is sometimes unavoidable, we
>>>>>>>>>>>>>>>>>>>>>>>>> should try not to introduce it in new structs.
>>>>>>>>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 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_r165119144
updated_at 2018-01-31 17:02:48
