Bill Fischofer(Bill-Fischofer-Linaro) 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 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_r161906756
updated_at 2018-01-16 22:41:16
