Dmitry Eremin-Solenikov(lumag) replied on github web page:
include/odp/api/spec/ipsec.h
line 8
@@ -232,6 +232,12 @@ typedef struct odp_ipsec_capability_t {
*/
odp_support_t pipeline_cls;
+ /** Implementation will automatically truncate TFC padding in received
+ * packets in ESP tunnel mode. Application can use this capability to
+ * determine necessity for ESP_TFC_PADDING_NOT_SUPPORTED notification.
+ */
+ odp_support_t tfc_padding_truncate;
Comment:
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_r162048705
updated_at 2018-01-17 13:26:04
