Petri Savolainen(psavol) 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:
L3 NONE is possible only in tunnel mode dummy case. In tunnel case, L4 type is
set to NONE by default, only if application has not requested extra parsing L4
type is set to e.g. TCP/UDP.
In transport mode, both L4 is set to NONE or NO_NEXT by default, and extra
parsing is needed for other values.
> Petri Savolainen(psavol) wrote:
> 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_r165285106
updated_at 2018-02-01 08:27:45
