JannePeltonen replied on github web page:
include/odp/api/spec/ipsec.h
@@ -1293,6 +1297,10 @@ int odp_ipsec_in(const odp_packet_t pkt_in[], int num_in,
* with IPSEC, etc headers constructed according to the standards. The amount
* and content of packet data before the IP header is undefined.
*
+ * Additional TFC padding might be present after packet payload for ESP-tunnel
+ * mode. It will be included into encrypted packet. Receiver side will skip
+ * this padding automatically.
+ *
Comment:
@Bill-Fischofer-Linaro I did not add the reference to the RFC.
@lumag Same comment also here about dropping the remark about the
ESP_TFC_PADDING_NOT_SUPPORTED notification. Actually, I think the whole last
added paragraph could be just removed.
> JannePeltonen wrote
> The reference to IKEv2 ESP_TFC_PADDING_NOT_SUPPORTED notification should be
> removed. IKE protocol details do not belong to this API spec which should
> just describe the API. One can read the IKE RFC for IKE details or one might
> not even use IKE but something else.
>
> Even when IKE is used, the remark is inaccurate. Even if we send the
> notification for some SA, it does not guarantee that the peer does not send
> us TFC padding but just declares that we do not accept such packets if we
> receive them.
>> Dmitry Eremin-Solenikov(lumag) wrote:
>> `odp_ipsec_in_enq()` just refers to `odp_ipsec_in()` function. As for inline
>> processing, an application should be prepared to receive them, because some
>> hardware can not drop them.
>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> I moved it to a separate comment, because of
>>> `ESP_TFC_PADDING_NOT_SUPPORTED` notification. I can still drop it.
>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>> Is this not equally applicable to `odp_ipsec_in_enq()`? And what about
>>>> packets received inline? Are we assuming that TFC dummy packets are
>>>> dropped by the inline RX path? That should also be documented if yes. If
>>>> not then application must be prepared to receive them that way as well.
>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>> I thought we discussed removing these capabilities from Tiger Moth?
>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>> @JannePeltonen I think @lumag's latest wording is concise. Any
>>>>>> application using TFC should be familiar with it's requirements and we
>>>>>> shouldn't have to repeat the RFC here.
>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>> OK. Agree with this approach for Tiger Moth.
>>>>>>>> JannePeltonen wrote
>>>>>>>> > I see no harm in keeping it
>>>>>>>>
>>>>>>>> I understand you refer to the tfc_padding_truncate capability. Note
>>>>>>>> that the proposal to get rid of it and discussion on that (with
>>>>>>>> comments from Petri too) are located elsewhere in this tool.
>>>>>>>>
>>>>>>>> That said, the harm of keeping the capability (in addition to growing
>>>>>>>> the API) is that the capability makes a promise that may (depending on
>>>>>>>> what value zero means) unnecessarily restrict implementations where
>>>>>>>> the fate of the padding is not the same globally in the whole system
>>>>>>>> and at all times (e.g. NIC based IPsec offload where padding is
>>>>>>>> removed or not depending no through which NIC the packet came in, or a
>>>>>>>> system where removal of the padding depends somehow on the packet).
>>>>>>>>
>>>>>>>> If the capability is kept, its meaning needs to be documented better,
>>>>>>>> including specifying what kinds of TFC padding it applies to (see
>>>>>>>> other comments regarding that).
>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>> @bala-manoharan @NikhilA-Linaro Please provide input here.
>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>> This is useful information for the application to know about how the
>>>>>>>>>> implementation will behave. Applications are free to ignore this if
>>>>>>>>>> they wish, but I see no harm in keeping it.
>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>> @psavol Yes, but it requires to call `odp_ipsec_result()` (which
>>>>>>>>>>> can be quite heavyweight). Currently it is possible to forward
>>>>>>>>>>> packets right after calling `odp_packet_has_error()` and
>>>>>>>>>>> `odp_packet_has_ipv4()`, which can be inlined to just bit checks.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, this is now a question to @bala-manoharan and
>>>>>>>>>>> @NikhilA-Linaro if it would be easy to add next_header field to
>>>>>>>>>>> `odp_ipsec_packet_result_t`
>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>> Application needs to anyway check if
>>>>>>>>>>>> * packet/ipsec operation result has errors
>>>>>>>>>>>> * IP version of packet (== what's in the tunnel)
>>>>>>>>>>>>
>>>>>>>>>>>> If we add result.next_header field, application can use that for
>>>>>>>>>>>> both checking IP version and NONH in one switch case. There's no
>>>>>>>>>>>> extra check for NONH.
>>>>>>>>>>>>
>>>>>>>>>>>> if (result.status != 0)
>>>>>>>>>>>> goto error;
>>>>>>>>>>>>
>>>>>>>>>>>> switch (result.next_header) {
>>>>>>>>>>>> case IPV4:
>>>>>>>>>>>> ....
>>>>>>>>>>>> case IPV6:
>>>>>>>>>>>> ....
>>>>>>>>>>>> case NONH:
>>>>>>>>>>>> odp_packet_free(pkt);
>>>>>>>>>>>> break;
>>>>>>>>>>>> default:
>>>>>>>>>>>> goto error;
>>>>>>>>>>>>
>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>> @psavol I agree with your arguments. However I'm worried about
>>>>>>>>>>>>> fast-forwarding use case. Do you think it will make sense to make
>>>>>>>>>>>>> tfc-packet warning (or even just flag) but still require that
>>>>>>>>>>>>> `odp_packet_has_error()` returns true for such packets?
>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>> From IPSEC operation point of view a successfully decrypted
>>>>>>>>>>>>>> dummy packet is a successful operation (SA matched, hash was OK,
>>>>>>>>>>>>>> decrypt was OK, protocol headers were OK, no replay issues,
>>>>>>>>>>>>>> etc). Just the payload format is different than usual. If TFC is
>>>>>>>>>>>>>> really used to hide traffic pattern, all spare capacity of the
>>>>>>>>>>>>>> connection could be filled by dummy packets. So, it would be
>>>>>>>>>>>>>> more common for application to receive these vs. the normal
>>>>>>>>>>>>>> packet (as long as HW is not dropping dummies).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, I'd like to reserve error/warning bits for the cases when
>>>>>>>>>>>>>> there's really a problem (SA configuration miss-match, attack,
>>>>>>>>>>>>>> broken sender implementation, etc).
>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>> We might add next_proto field to packet_result. @NikhilA-Linaro
>>>>>>>>>>>>>>> how hard would it be to get this field on your platform?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm against using warning bit for dummy packets. From ODP
>>>>>>>>>>>>>>> packet flow point of view, dummy packet is clearly an
>>>>>>>>>>>>>>> errorneous packet.
>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>> Hmm... I misread the specification so LOOKUP_DSTADDR_SPI only
>>>>>>>>>>>>>>>> uses ip addr and proto field for lookup and does not validate
>>>>>>>>>>>>>>>> the src/dst ip address or proto filed after decryption. I
>>>>>>>>>>>>>>>> believe this validation of IP addr and version can be done by
>>>>>>>>>>>>>>>> the HW and could be something to add as an enhancement to the
>>>>>>>>>>>>>>>> spec in the future.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, we could add this SA to packet result but since the RFC
>>>>>>>>>>>>>>>> specifies in the implementation note to discard the dummy
>>>>>>>>>>>>>>>> packet after the reception I was inclined towards not updating
>>>>>>>>>>>>>>>> these structures for dummy packets.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What is your opinion on updating the next protocol field in
>>>>>>>>>>>>>>>> odp_packet_result vs adding a warning bit for dummy packet?
>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>> ODP_IPSEC_LOOKUP_DSTADDR_SPI means that for an SA to match a
>>>>>>>>>>>>>>>>> received packet, both the SPI and the destination IP address
>>>>>>>>>>>>>>>>> of the received ESP/AH packet must match those configured in
>>>>>>>>>>>>>>>>> the SA. This lookup must happen before IPsec processing
>>>>>>>>>>>>>>>>> (decryption), i.e. before it is even possible to know that
>>>>>>>>>>>>>>>>> the packet is actually a dummy TFC packet. You have to find
>>>>>>>>>>>>>>>>> the correct SA and perform decryption before you can tell
>>>>>>>>>>>>>>>>> whether a received packet is a genuine data packet or a dummy
>>>>>>>>>>>>>>>>> TFC packet.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An application expects the used SA to be set in the packet
>>>>>>>>>>>>>>>>> result and, IMHO, dummy packets should not be any different
>>>>>>>>>>>>>>>>> since they got processed using the SA.
>>>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>>>> I was referring to ODP_IPSEC_LOOKUP_DSTADDR_SPI. This cannot
>>>>>>>>>>>>>>>>>> be matched in case of NH = 59. Actually, this raises
>>>>>>>>>>>>>>>>>> another question. Do you really need the SA from which this
>>>>>>>>>>>>>>>>>> Dummy packet was received in the application? Like do we
>>>>>>>>>>>>>>>>>> have to fill the SA value in the odp_ipsec_packet_result_t
>>>>>>>>>>>>>>>>>> field?
>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>> What selector checks are you referring to? Traffic
>>>>>>>>>>>>>>>>>>> selectors are handled fully in the application side. The
>>>>>>>>>>>>>>>>>>> ODP implementation does not know the traffic selectors and
>>>>>>>>>>>>>>>>>>> cannot do any checks anyway.
>>>>>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>>>>>> We added this capability mainly coz NXP were removing the
>>>>>>>>>>>>>>>>>>>> padding and Cavium was not removing the padding. If from
>>>>>>>>>>>>>>>>>>>> the application point of view you are fine with the
>>>>>>>>>>>>>>>>>>>> wording you have suggested above then this capability can
>>>>>>>>>>>>>>>>>>>> be removed.
>>>>>>>>>>>>>>>>>>>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>>>>>>>>>>>>>>>>>>>> In case if we update the warning bit when the dummy
>>>>>>>>>>>>>>>>>>>>> packet is found then there will not be much impact on the
>>>>>>>>>>>>>>>>>>>>> application side since odp_ipsec_status_t consists both
>>>>>>>>>>>>>>>>>>>>> error and warning bits. Updating next proto field in
>>>>>>>>>>>>>>>>>>>>> ipsec_op_packet_result_t requires implementation to
>>>>>>>>>>>>>>>>>>>>> process and update this field for every packet.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The only API change required is to specify clearly that
>>>>>>>>>>>>>>>>>>>>> in-case of a dummy packet the implementation will not do
>>>>>>>>>>>>>>>>>>>>> any selector checks on the received packets.
>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>> I was just pointing out that from functional
>>>>>>>>>>>>>>>>>>>>>> completeness perspective API changes are not strictly
>>>>>>>>>>>>>>>>>>>>>> needed. But as was discussed in the Wednesday meeting,
>>>>>>>>>>>>>>>>>>>>>> having the next header field in the packet result could
>>>>>>>>>>>>>>>>>>>>>> be useful and convenient anyway.
>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>> The issue with transport mode ESP and NONH is that we
>>>>>>>>>>>>>>>>>>>>>>> should never forward NOHN packets even in transport
>>>>>>>>>>>>>>>>>>>>>>> mode. So both transport and tunnel NONH packets should
>>>>>>>>>>>>>>>>>>>>>>> raise same exceptions.
>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>> I do not think it is necessary. The next header field
>>>>>>>>>>>>>>>>>>>>>>>> can be anything (like TCP) in transport mode, but in
>>>>>>>>>>>>>>>>>>>>>>>> transport mode this API delivers the application and
>>>>>>>>>>>>>>>>>>>>>>>> IP packet and inserts the protocol value from the next
>>>>>>>>>>>>>>>>>>>>>>>> header field in the protocol field of the IP header.
>>>>>>>>>>>>>>>>>>>>>>>> For tunnel mode SAs other next header values than
>>>>>>>>>>>>>>>>>>>>>>>> those for IPv4, IPv6 and dummy packets should not
>>>>>>>>>>>>>>>>>>>>>>>> appear.
>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Maybe a generic solution would be to add the IPSEC
>>>>>>>>>>>>>>>>>>>>>>>>> next header field value into
>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_packet_result_t. I guess all
>>>>>>>>>>>>>>>>>>>>>>>>> implementations should be able to return that after
>>>>>>>>>>>>>>>>>>>>>>>>> decrypt as RFCs mention also TCP as one possible
>>>>>>>>>>>>>>>>>>>>>>>>> value. So, payload could be at least IPv4, IPv6, TCP
>>>>>>>>>>>>>>>>>>>>>>>>> or NONH.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> " The value of this
>>>>>>>>>>>>>>>>>>>>>>>>> field is chosen from the set of IP Protocol
>>>>>>>>>>>>>>>>>>>>>>>>> Numbers defined on the
>>>>>>>>>>>>>>>>>>>>>>>>> web page of Internet Assigned Numbers Authority
>>>>>>>>>>>>>>>>>>>>>>>>> (IANA). For example,
>>>>>>>>>>>>>>>>>>>>>>>>> a value of 4 indicates IPv4, a value of 41
>>>>>>>>>>>>>>>>>>>>>>>>> indicates IPv6, and a
>>>>>>>>>>>>>>>>>>>>>>>>> value of 6 indicates TCP."
>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>> Currently the API promises to give the original
>>>>>>>>>>>>>>>>>>>>>>>>>> packet back to the application in case of any error.
>>>>>>>>>>>>>>>>>>>>>>>>>> This would apply to dummy packets too. Maybe the API
>>>>>>>>>>>>>>>>>>>>>>>>>> should be so that such preservation of the original
>>>>>>>>>>>>>>>>>>>>>>>>>> packet is not required in the case of dummy packets
>>>>>>>>>>>>>>>>>>>>>>>>>> to reduce the overhead of handling dummy packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Reporting dummy packet through an error is a bit
>>>>>>>>>>>>>>>>>>>>>>>>>> misleading since no error happened. An application
>>>>>>>>>>>>>>>>>>>>>>>>>> cannot e.g. have a global IPsec error counter
>>>>>>>>>>>>>>>>>>>>>>>>>> without first filtering out dummy packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>> A dummy packet in transport mode could be delivered
>>>>>>>>>>>>>>>>>>>>>>>>>>> to an application in the normal way. The result
>>>>>>>>>>>>>>>>>>>>>>>>>>> packet would be an IP packet with protocol 59. But
>>>>>>>>>>>>>>>>>>>>>>>>>>> it is true that in tunnel mode there is no way to
>>>>>>>>>>>>>>>>>>>>>>>>>>> deliver the packet to the application in the
>>>>>>>>>>>>>>>>>>>>>>>>>>> current API. In my interpretation of the current
>>>>>>>>>>>>>>>>>>>>>>>>>>> API a tunnel mode dummy packet would result in a
>>>>>>>>>>>>>>>>>>>>>>>>>>> proto error (since the decapsulated packet is
>>>>>>>>>>>>>>>>>>>>>>>>>>> neither IPv4 nor IPv6).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> So some warning/error/flag bit is indeed needed if
>>>>>>>>>>>>>>>>>>>>>>>>>>> one does not want to confuse dummy packets with
>>>>>>>>>>>>>>>>>>>>>>>>>>> protocol errors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is in conflict with this existing statement a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> little earlier:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Additionally, input IP packet length
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (odp_packet_len() minus odp_packet_l3_offset())
>>>>>>>>>>>>>>>>>>>>>>>>>>>> must match values in protocol headers. Otherwise
>>>>>>>>>>>>>>>>>>>>>>>>>>>> esults are undefined."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It could be reworded like this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Additionally, input L3 packet length
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (odp_packet_len() minus odp_packet_l3_offset())
>>>>>>>>>>>>>>>>>>>>>>>>>>>> must not be smaller than the IP packet lenght
>>>>>>>>>>>>>>>>>>>>>>>>>>>> indicated by the IP header. Otherwise results are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> undefined. If the input L3 packet length is bigger
>>>>>>>>>>>>>>>>>>>>>>>>>>>> than the IP packet length, the additional packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>> data is used as TFC padding."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> And I think that would be sufficient about TFC
>>>>>>>>>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I suggest rewording like this (after dropping
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tfc_padding_truncate capa):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> An inbound ESP packet may contain TFC padding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_in() might or might not remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding. When TFC padding is not removed, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> resulting ODP packet will extend beyond the end
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the IP packet it contains or the resulting IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet will extend beyond the end of the IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> payload protocol. An ODP application can detect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and remove such padding by inspecting the length
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fields of the relevant protocol headers in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result packet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer to have this bit as an error to keep
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> very simple constraint. No error => app may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forward packet (if it is not interested in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details). Error => packet must be threated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> separately and must not be forwarded.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> True.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fine, I'll drop this and add a phrase that an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation might have removed the padding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They can not come as "normal" packets. An
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application will have no way to determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the package was dummy after receiving
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it. NH field will be gone in case of tunnel
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I suggest that when implementation does not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drop "no next header" packets, those come
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through as any other successfully
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transformed packets: no error/warning bits
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set. However, when HW has dropped a no NH
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet it generates a dummy packet (length
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> zero, etc) with a warning or operation flag
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bit on telling that this is not a normal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet, but an indication that a no NH
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet was dropped.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Errors/warnings indicate a failure and may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> require some specific action (SA
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> negotiation). This instead could be could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just a odp_ipsec_op_flag_t bit, as the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation was successful and does not need
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specific action (other than drop packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after finding out that it does not contain
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any data). So, application could ignore the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bit and drop packet as part of normal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing of too short packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also this capa is not strictly needed. A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> portable application will need to handle
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also the case where inline input does not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drop NH packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I still vote for minimal TFC specific API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> changes at this point. This capa is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly needed. A portable application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would need to implement the length checks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyway.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have to think about it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This will allow fast-path forwarding for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some applications. If this flag is set,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an application can skip header
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checks/lookups and forward ready packet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will update wording to match RFC.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Noted that ODP does not touch TFC
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding in transport mode.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you are saying that my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interpretation was not the intended
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one. I think it is important to make
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it clear whether we mean that there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might of might not be padding in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> received packet in the first place or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether the implementation might or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might not strip said padding when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> present.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I was thinking it would be good to not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make any promises on whether the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding is removed or not, i.e.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specify that there may or may not be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding left in the result packet that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the application gets. This would work
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with any implementation, even those
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that do not always do the same thing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for every packet (e.g. depending on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input port).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not promising anything about the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding would be similar to how the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> API currently leaves it up to the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation whether there is any L2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or other bytes in front of the IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> header in the ODP packet data.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Anyway, I will not attempt better
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wording before it is clear what the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended semantics are.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @psavol @JannePeltonen for async the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> major issue is the packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> metadata/user pointer here. I think
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we might need to give some thought to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this area anyway because of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fragmentation handling. We might need
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> additional copy_udata/free_udata
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function pointers to sa config.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, but is it needed? With this, an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application could check if the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capability was set instead of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checking if packet length is bigger
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than the header indicates for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deciding whether to trim padding. I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just wonder if that is beneficial
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enough to justify yet another
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capability flag.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Well. RX side has no way to know in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> advance if there will TFC padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not in the packet. That is why I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used "might" here. Could you please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> suggest better wording?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @JannePeltonen
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Basically it is there to describe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hardware behaviour. NXP SEC
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> truncates packets according to L4
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> length, our hardware does not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Updating to specifically mention
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "inline" mode. We can add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drop/etc. settings to sync/async
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> modes later.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... my point being, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> description should be improved
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to make it more accurate and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unambiguous.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The term "TFC padding" in this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> API proposal seems to differ
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from that in the RFC. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> appears that here TFC padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> refers only to padding after IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> payload in tunnel mode.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC padding, as defined in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RFC, is not restricted to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tunnel mode. Transport mode
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which carries e.g. UDP or IP or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other suitable protocol can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have TFC padding but that can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not be recognized by ODP in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> general case (e.g. with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proprietary IP protocols).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I interpret the "might be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> present" so that if there was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC padding in a received
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet, it might or might not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be present after ODP IPsec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing. Is that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended interpretation and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does it need to be made
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clearer?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is the tfc_padding_truncate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capability even needed? It is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an optimization for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applications that would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> benefit from knowing in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> advance that the padding is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> always truncated, but is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there a good use case for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The documentation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_ipsec_in() says:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Outputted packets with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> error status have not been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transformed but the original
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet is returned."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe it is too much
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> promised for TFC packets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (and the application should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not need the original packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in that case anyway). It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would anyway be good to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clarify in the comments how
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exactly odp_ipsec_in()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behaves with TFC packets.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JannePeltonen wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I understood that we wanted
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the automatic dropping only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in inline processing mode
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and not in other modes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We should minimize the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of configuration
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> options at this time. I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> think it's not important
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for application to control
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dummy packet dropping. So,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be implementation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined in inline. For
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sync/async we must defined
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> how many packets can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expected back from each
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IPSEC operation. The
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simplest would be that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> each input packet produces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an output packet, and it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation specific
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what the output packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contains (NONH packet or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just a warning flag
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> telling that the packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was dropped since it was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NONH). Application would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not need to control
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dropping but notice if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that happened. Async
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface would be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problematic for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application if it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible that nothing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comes back from an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation (all packets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> silently dropped).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hmm. What about
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packet_drop_sync/async/inline_configurable`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capabilities and three
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> flags
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packet_drop_sync/async/inline`?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NikhilA-Linaro wrote
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This configuration
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> option is a bit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> confusing. We need to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifically mention
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inline and look aside
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cases. It may not be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurable in many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hardwares.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some implementations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> may be able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configure this behavior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_ipsec_config()`,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in which case
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_support_t` would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be useful. We can make
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that change later, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it just looks more
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent here. Not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> big deal, however.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ok, updated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because it's not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> declaration of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supporting a feature
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but rather a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> statement how
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handles this case. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not possible to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> switch it. So I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> preferred to have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_bool_t here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packets_drop`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would be clearer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you're
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> referencing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_padding_truncate`,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the TFC prefix
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would seem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent here. So
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `tfc_dummy_packets_drop`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and comments
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should similarly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reference TFC.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_support_t`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same as other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capabilities here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, then I would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make it clear
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that these are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supplied by the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application. For
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> may choose to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insert additional
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding bytes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after the packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> payload (bytes in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the packet beyond
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IP length). These
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be included
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the encrypted
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> output packet, to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be skipped by the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> receiver.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I wouldn't make
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> representations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about automatic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> skipping since
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there's no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assurance that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the receiver is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an ODP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application so we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't say what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recipient will do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nothing controls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> padding bytes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is up to an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eremin-Solenikov(lumag)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might be no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> associated with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such event.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> information
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that there was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TFC packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What controls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the number of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes? This
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> documented.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Fischofer(Bill-Fischofer-Linaro)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this were
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> `odp_ipsec_packet_result_t`
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bit rather
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than a status
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> event all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input packets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (synchronous,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asynchronous,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and inline)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cases could
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be handled
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> without the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TBD. Why use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> status events
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for these
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets?
https://github.com/Linaro/odp/pull/329#discussion_r162637151
updated_at 2018-01-19 14:35:17
