Dmitry Eremin-Solenikov(lumag) replied on github web page:
include/odp/api/spec/ipsec.h
line 167
@@ -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
Comment:
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_r165119101
updated_at 2018-01-31 17:02:39
