Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
include/odp/api/spec/ipsec.h
line 36
@@ -1223,9 +1223,12 @@ typedef struct odp_ipsec_status_t {
* Each successfully transformed packet has a valid value for these metadata
* regardless of the inner packet parse configuration
* (odp_ipsec_inbound_config_t):
- * - L3 offset: Offset to the first byte of the (outmost) IP header
- * - pktio: For inline IPSEC processed packets, original packet input
- * interface
+ * - L3 offset: Offset to the first byte of the (outmost) IP header
+ * - IPv4/IPv6 flags: These flags can be used to determine packet contents.
+ * If neither IPv4 nor IPv6 flag are set, received packet is
+ * TFC dummy packet and should be dropped by an application
+ * - pktio: For inline IPSEC processed packets, original packet input
+ * interface
Comment:
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_r161907949
updated_at 2018-01-16 22:41:16
