Petri Savolainen(psavol) 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:
L3 types are basically what you find from L2 type field: ARP, RARP, IPV4, IPV6.
There's no "no next header" type in e.g. ethernet types. So, NO_NEXT is defined
only on L4 types. But that's OK since, for tunnel mode application just checks
agaist l3_type == IPV4, IPV6 or NONE, where NONE == dummy. In transport mode,
application just checks l4_type == NO_NEXT for dummy. Application L3 type in
transport should always have either IPV4 or IPV6.
> Dmitry Eremin-Solenikov(lumag) wrote:
> 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_r165284528
updated_at 2018-02-01 08:24:29
