Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
include/odp/api/spec/ipsec.h
@@ -1206,6 +1210,14 @@ typedef struct odp_ipsec_status_t {
* restored. The amount and content of packet data before the IP header is
* undefined.
*
+ * Additional TFC padding might be present after packet contents. For ESP
+ * transport mode ODP does not truncate such padding, it up to an application
+ * to detect and drop it. For ESP tunnel mode, received side can use total
+ * (IPv4) or payload (IPv6) length from internal headers to drop such TFC
+ * padding. If tfc_padding_truncate capability is set, implementation will
+ * truncate received packets automatically. Otherwise ODP application has to
+ * truncate packets manually.
+ *
Comment:
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_r161905887
updated_at 2018-01-16 22:41:16
