Petri Savolainen(psavol) replied on github web page:
include/odp/api/spec/packet.h
line 38
@@ -1378,12 +1394,44 @@ uint32_t odp_packet_l4_offset(odp_packet_t pkt);
int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t offset);
/**
+ * Layer 3 checksum check status
+ *
+ * Returns the result of the latest layer 3 checksum check done for the packet.
+ * The status tells if checksum check was attempted and the result of the
+ * attempt. It depends on packet input (or IPSEC) configuration, packet content
+ * and implementation capabilities if checksum check is attempted for a packet.
+ *
+ * @param pkt Packet handle
+ *
+ * @return L3 checksum check status
+ */
+odp_packet_chksum_status_t odp_packet_l3_chksum_status(odp_packet_t pkt);
Comment:
With my proposal application may always reduce the number of return values by
itself:
static inline has_l3_csum(odp_packet_t pkt) {
return odp_packet_l3_chksum_status(pkt) != ODP_PACKET_CHKSUM_UNKNOWN;
}
Also, sometimes application may want to know which error(s) packet has. E.g. it
may not tolerate length errors, but a checksum error may be OK for some
packets.
A non-inlined function call is about 7-8 CPU cycles. L2fwd cycle count is
around 130-250 cycles (no-copy vs copy) per packet (non ABI compat). A real
application could be around 500 cycles per packet (ABI compat). That's about
-1.5% max packet rate for every extra function call.
> psavol wrote
> Actually, âcorrect: 0/1â already exists:
> error_flags.ip_err
> error_flags.tcp_err
> error_flags.udp_err
>
> And existing API:
> int odp_packet_has_l3_error(odp_packet_t pkt);
> int odp_packet_has_l4_error(odp_packet_t pkt);
>
> What is needed (from my point in view) is âchecked: 0/1â:
>
> int odp_packet_has_l3_csum(odp_packet_t pkt);
> int odp_packet_has_l4_csum(odp_packet_t pkt);
>
> I suggest to go with this for a cleaner API.
>
> Anyway, one function call or two is less relevant for a ârealâ
> application: only if csum was done or not is really important. The âcostâ
> for the extra call is not significant and can be avoided.
>> Petri Savolainen(psavol) wrote:
>> odp-linux implementation will add two bits into p.input_flags (checked: 0/1,
>> correct: 0/1), other implementations read/check something else from their
>> packet descriptor.
>>> Petri Savolainen(psavol) wrote:
>>> It is applicable to that as well. Also there application should pass
>>> **full** packets to (L4 checksum) offload, which then processes those in
>>> correct order (checksum + fragment + crypt, etc). Application should not
>>> ask impossible things like - insert L4 checksum when there's not L4 header
>>> (fragments).
>>>> Petri Savolainen(psavol) wrote:
>>>> The problem of lazy parsing (incl checksum) is that application may alter
>>>> the packet before asking something about it. Parser results reflect the
>>>> packet format when it first arrived the system.
>>>>
>>>> Agree with Janne that cheap checksum status check is needed to avoid ODP
>>>> implementation to do extra work for nothing.
>>>>> Petri Savolainen(psavol) wrote:
>>>>> Same answer here. Checksum check during packet input has "zero" CPU
>>>>> overhead. This API is used exploit that offload. When input HW didn't do
>>>>> it (for some reason), may be application does not care it (since it
>>>>> didn't need to check this packet) or does it on SW. We can add ones'
>>>>> complement sum ODP API, etc to assist in that.
>>>>>> Petri Savolainen(psavol) wrote:
>>>>>> The point is that we must be careful what is requested as a must from
>>>>>> ODP (for every packet). E.g. ODP does not know on which packets
>>>>>> application cares about checksum and on which not. If we require that
>>>>>> ODP always checks checksum for all packets (also when HW cannot do it),
>>>>>> an implementation ends up routing packets to spare cores and back for
>>>>>> SW checksum, which application may very well ignore when received
>>>>>> (since it was forwarding and not terminating those).
>>>>>>
>>>>>> This API introduces the HW independent way to check if HW has checked
>>>>>> the packet. We can add full and partial checksum functions (to ODP API)
>>>>>> for application assist, when HW check was not done for one reason or the
>>>>>> other. This is optimal since not application calls for the SW checking
>>>>>> only when it's really needed.
>>>>>>
>>>>>>> psavol wrote
>>>>>>> There are actually more than 3 cases when we think about the usage of
>>>>>>> the result. Basically for each 3 cases you list, there are 2 subcases:
>>>>>>> a) The application wants to know that the checksum is correct (i.e. it
>>>>>>> actually receives the packet) b) The application does not care about
>>>>>>> the correctness of the checksum either because the packet gets dropped
>>>>>>> anyway for other reasons or because it is L4 checksum and the packet is
>>>>>>> going to be forwarded and should not be dropped even if the L4 checksum
>>>>>>> is not correct.
>>>>>>>
>>>>>>> So, with checksum offload enabled, an application should not use
>>>>>>> odp_packet_has_error() for forwarded packets but
>>>>>>> odp_packet_has_l2_error() and odp_packet_has_l3_error() instead.
>>>>>>>> psavol wrote
>>>>>>>> In the RX side there are valid use cases where we both care and do not
>>>>>>>> care about the L4 checksum. If a system is both forwarding and
>>>>>>>> terminating IP traffic and neither clearly dominates the other, then
>>>>>>>> we want to be able to take advantage of HW checksum checking without
>>>>>>>> unnecessarily doing SW checksum checking when it is not needed.
>>>>>>>>
>>>>>>>> ODP implementation cannot determine which packets are going to be
>>>>>>>> forwarded (and for which checking the L4 checksum would be a waste of
>>>>>>>> resources) and which are locally received (and L4 checksum must be
>>>>>>>> checked). The application knows it.
>>>>>>>>
>>>>>>>> It would be good if an application would be able to request "cheap"
>>>>>>>> (i.e. done in HW, not in SW) L4 checksum checking for all incoming
>>>>>>>> packets and later decide whether the result of the checksum check is
>>>>>>>> actually used and whether to fall back to the much more costly SW
>>>>>>>> calculation (once it is known for which packets the check is needed.
>>>>>>>>
>>>>>>>> Maybe the API proposal is not clear enough of the intention of
>>>>>>>> enabling this, but this is what we have needed the past in actual
>>>>>>>> products and this is what we have implemented (in totally different
>>>>>>>> context than ODP).
>>>>>>>>
>>>>>>>> Maybe one possibility would be to have ODP always check the L4
>>>>>>>> checksum but do the SW fallback only when the checksum result is being
>>>>>>>> requested. If the application checks the L4 checksum result only when
>>>>>>>> it knows that it needs to check it, the SW calculation would not be
>>>>>>>> done in vain for other packets.
>>>>>>>>
>>>>>>>> Even for applications that only terminate all traffic and thus need to
>>>>>>>> check the L4 checksum, it would make sense to postpone the SW fallback
>>>>>>>> until it is known that the checksum result is really needed (and the
>>>>>>>> packet did not fail any other checks, i.e. had proper L3 checksum, the
>>>>>>>> right IP addresses and ports etc).
>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>> OK. It may be worthwhile to include that clarification here so that
>>>>>>>>> applications have assurance that this is not applicable to IPsec
>>>>>>>>> inline output.
>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>> ODP APIs say nothing about what HW can or cannot do since the APIs
>>>>>>>>>> don't presume any implementation model. They describe the services
>>>>>>>>>> that ODP implementations provide in a platform-optimal manner.
>>>>>>>>>> Ideally that means in HW, but if a given platform requires SW to
>>>>>>>>>> provide that service in general, or in a specific case, then the
>>>>>>>>>> implementation is in a better position to do that optimally than the
>>>>>>>>>> application.
>>>>>>>>>>
>>>>>>>>>> If the intent here is to request only services that are HW
>>>>>>>>>> accelerated, then they should be recast in that light. But in the
>>>>>>>>>> case of checksumming, it's not as if this can be skipped if it's
>>>>>>>>>> "too hard" to do in HW. So I'd rather see ODP do it in SW once than
>>>>>>>>>> requiring every application to duplicate this effort.
>>>>>>>>>>> psavol wrote
>>>>>>>>>>> There are 3 cases:
>>>>>>>>>>>
>>>>>>>>>>> 1. Csum was done + success
>>>>>>>>>>> 2. Csum was done + error
>>>>>>>>>>> 3. Csum was not done
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> First thing you will usually do with a packet (for N number of
>>>>>>>>>>> reasons):
>>>>>>>>>>>
>>>>>>>>>>> If (odp_packet_has_error())
>>>>>>>>>>> odp_packet_free(pkt);
>>>>>>>>>>>
>>>>>>>>>>> This will remove packets with âCsum was done + errorâ.
>>>>>>>>>>> The only question remaining: âCsum was done + successâ or
>>>>>>>>>>> âCsum was not doneâ
>>>>>>>>>>>
>>>>>>>>>>> More, the implementation will likely put this info in
>>>>>>>>>>> odp_packet_hdr(pkt)->p.input_flags, so it makes sense to look like
>>>>>>>>>>> the other APIs from there.
>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>> The application determines whether L3 checksum processing is
>>>>>>>>>>>> needed or not. If it says it is needed, then I don't see why it's
>>>>>>>>>>>> unreasonable to expect the ODP implementation to do it. Is
>>>>>>>>>>>> requiring every application to do this in SW somehow better than
>>>>>>>>>>>> having ODP do it commonly in SW?
>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>> @JannePeltonen I thought that's why we were providing the
>>>>>>>>>>>>> per-packet override capability here--so that applications can say
>>>>>>>>>>>>> "While I normally want checksums added, for this packet that's
>>>>>>>>>>>>> not needed". Or "Please don't add checksums by default, however
>>>>>>>>>>>>> for this packet please do so". The point is, if the application
>>>>>>>>>>>>> determines that checksum processing is needed for a particular
>>>>>>>>>>>>> packet (or interface) then that work needs to be done. The ODP
>>>>>>>>>>>>> implementation is in a better position than the application to
>>>>>>>>>>>>> determine how best to do that work on this platform since it has
>>>>>>>>>>>>> direct access to the platform-specific HW, specialized
>>>>>>>>>>>>> instructions, etc., and if it needs to fall back to SW can do so
>>>>>>>>>>>>> using instruction sequences optimized to its microarchitecture.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On the RX side, again we either don't care about checksum
>>>>>>>>>>>>> validation or else we do. If we do then that work has to be done.
>>>>>>>>>>>>> So I don't see what advantage is gained by requiring every
>>>>>>>>>>>>> application to have a "backup plan" in this area.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, since ODP requires the application to have correctly set
>>>>>>>>>>>>> the L3 and L4 offset values, that's all the information required
>>>>>>>>>>>>> to perform these calculations as specified by the relevant RFCs
>>>>>>>>>>>>> independent of the rest of the packet structure. So again, it's
>>>>>>>>>>>>> cleaner to have ODP do that once rather than requiring every
>>>>>>>>>>>>> application to duplicate that effort.
>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>> Why you'd prefer two calls instead of one? With ABI compat, the
>>>>>>>>>>>>>> number of function calls per packet matters. Also, "has
>>>>>>>>>>>>>> checksum been checked" and "checksum check result" are likely
>>>>>>>>>>>>>> reading the same bits in packet header anyway. So, it makes
>>>>>>>>>>>>>> sense to do both checks in one go.
>>>>>>>>>>>>>>> psavol wrote
>>>>>>>>>>>>>>> Instead of this I would prefer to have in
>>>>>>>>>>>>>>> ./include/odp/api/spec/packet_flags.h /
>>>>>>>>>>>>>>> ./platform/linux-generic/odp_packet_flags.c something like:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int odp_packet_has_l3_csum(odp_packet_t pkt);
>>>>>>>>>>>>>>> int odp_packet_has_l4_csum(odp_packet_t pkt);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * @retval non-zero operation was performed
>>>>>>>>>>>>>>> * @retval 0 operation was not performed
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For completeness, we may add explicit csum operation result
>>>>>>>>>>>>>>> call but likely odp_packet_has_error() or
>>>>>>>>>>>>>>> odp_packet_has_l3_error() or odp_packet_has_l4_error() will be
>>>>>>>>>>>>>>> preferred.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int odp_packet_has_l3_csum_error(odp_packet_t pkt);
>>>>>>>>>>>>>>> int odp_packet_has_l4_csum_error(odp_packet_t pkt);
>>>>>>>>>>>>>>>> psavol wrote
>>>>>>>>>>>>>>>> It would not be good to require ODP to always check the L4
>>>>>>>>>>>>>>>> checksum if checksum checking is enabled in the config,
>>>>>>>>>>>>>>>> because then some implementations might have to fall back to
>>>>>>>>>>>>>>>> SW checking for some packets and doing the check in SW would
>>>>>>>>>>>>>>>> be a waste of resources in case the application is not
>>>>>>>>>>>>>>>> interested in the L4 checksum of all packets (e.g. an
>>>>>>>>>>>>>>>> application that both terminates and forwards IP packets needs
>>>>>>>>>>>>>>>> to check the L4 checksum of the locally received packets but
>>>>>>>>>>>>>>>> should ignore the L4 checksum of forwarded packets.
>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>> This talks **application** passing fragments to ODP for L4
>>>>>>>>>>>>>>>>> checksum insertion. When ODP IPsec inline creates fragments,
>>>>>>>>>>>>>>>>> application does not have control on those (no need for API
>>>>>>>>>>>>>>>>> spec) and obviously implementation must not trick itself
>>>>>>>>>>>>>>>>> (it's an implementation internal bug to create a fragment and
>>>>>>>>>>>>>>>>> ask output HW to insert L4 checksum for those).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Application passes full packet to IPSEC with fragmentation
>>>>>>>>>>>>>>>>> and L4 checksum offload requests - implementation inserts L4
>>>>>>>>>>>>>>>>> checksum, does fragmentation if needed, passes new packets
>>>>>>>>>>>>>>>>> back to user or directly to output (in case of inline).
>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>> The intention is best effort on top of the minimum
>>>>>>>>>>>>>>>>>> requirement that all basic IP packets must be checked. The
>>>>>>>>>>>>>>>>>> wording says that quite clearly already (what needs to
>>>>>>>>>>>>>>>>>> change ?). Again it's a fact that not all HW will check
>>>>>>>>>>>>>>>>>> non-basic IP packets, or if they do (e.g. with firmware /
>>>>>>>>>>>>>>>>>> SW) packet rate may be much lower for _all_ packets.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Typically, these non-basic packets are a small fraction of
>>>>>>>>>>>>>>>>>> all packets and belong to the slow path anyway.
>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>> That's RFC for IP stack not for NIC HW. ODP just pass
>>>>>>>>>>>>>>>>>>> information between app and HW. IP stack is an app. So, the
>>>>>>>>>>>>>>>>>>> app (IP stack) must do checksum check if HW didn't do it.
>>>>>>>>>>>>>>>>>>> We leave option for the HW to not do it, since not all HW
>>>>>>>>>>>>>>>>>>> do it for packets with options/extensions.
>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>> About the values, we can change those later if there's
>>>>>>>>>>>>>>>>>>>> evidence from various implementations that OK == 0 would
>>>>>>>>>>>>>>>>>>>> be better than UNKNOWN == 0. If there's no measurable
>>>>>>>>>>>>>>>>>>>> performance difference, UNKNOWN == 0 is more robust as
>>>>>>>>>>>>>>>>>>>> init value.
>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>> These three values are needed. For example, we cannot
>>>>>>>>>>>>>>>>>>>>> dictate that all HW must be able to calculate checksums
>>>>>>>>>>>>>>>>>>>>> when there are extension headers. Still some HW can do
>>>>>>>>>>>>>>>>>>>>> that. So, even if application enabled checksumming, it
>>>>>>>>>>>>>>>>>>>>> depends on the packet and on the implementation if check
>>>>>>>>>>>>>>>>>>>>> was done or not. We just dictate that basic packets (no
>>>>>>>>>>>>>>>>>>>>> options / extensions) must always be checked when
>>>>>>>>>>>>>>>>>>>>> checksumming is enabled.
>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>> OK
>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>> Then perhaps the 0 enum should be
>>>>>>>>>>>>>>>>>>>>>>> `ODP_PACKET_CHECKSUM_NORMAL` where "normal" is
>>>>>>>>>>>>>>>>>>>>>>> interpreted as OK if checksum offload was requested and
>>>>>>>>>>>>>>>>>>>>>>> "unknown" if it was not requested. The enum is then
>>>>>>>>>>>>>>>>>>>>>>> simply either NORMAL or BAD. The point is the only
>>>>>>>>>>>>>>>>>>>>>>> thing the application really wants to know is whether
>>>>>>>>>>>>>>>>>>>>>>> the checksum is bad or not. If it's disabled
>>>>>>>>>>>>>>>>>>>>>>> checksumming for whatever reason then presumably it
>>>>>>>>>>>>>>>>>>>>>>> doesn't care.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If we reduce the enum to only two values, then it can
>>>>>>>>>>>>>>>>>>>>>>> simply collapse into a "bad" bit that's set if we know
>>>>>>>>>>>>>>>>>>>>>>> the checksum is incorrect and left as 0 otherwise. The
>>>>>>>>>>>>>>>>>>>>>>> 0 means it's OK if we are checking checksums and
>>>>>>>>>>>>>>>>>>>>>>> unknown if we don't care about them.
>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Agreed, however whether IPsec fragments the output for
>>>>>>>>>>>>>>>>>>>>>>>> a given packet may not be known in advance by the
>>>>>>>>>>>>>>>>>>>>>>>> application. As worded, this would seem to imply that
>>>>>>>>>>>>>>>>>>>>>>>> I cannot request L4 checksum processing for inline
>>>>>>>>>>>>>>>>>>>>>>>> IPsec output on the off chance it may need to be
>>>>>>>>>>>>>>>>>>>>>>>> fragmented. I doubt if that is your intent here.
>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Again, TCP checksums are not optional and their
>>>>>>>>>>>>>>>>>>>>>>>>> presence is not conditional upon such things. If the
>>>>>>>>>>>>>>>>>>>>>>>>> intent here is to request best-effort HW offload (as
>>>>>>>>>>>>>>>>>>>>>>>>> opposed to requiring the ODP implementation provide
>>>>>>>>>>>>>>>>>>>>>>>>> this service however it chooses) then this wording
>>>>>>>>>>>>>>>>>>>>>>>>> needs to change to reflect that distinction. I'd take
>>>>>>>>>>>>>>>>>>>>>>>>> the position that applications should never have to
>>>>>>>>>>>>>>>>>>>>>>>>> worry about checksums unless they are being
>>>>>>>>>>>>>>>>>>>>>>>>> overridden for specific diagnostic or other purposes.
>>>>>>>>>>>>>>>>>>>>>>>>> In normal operation applications should be able to
>>>>>>>>>>>>>>>>>>>>>>>>> rely on the ODP implementation taking care of them
>>>>>>>>>>>>>>>>>>>>>>>>> (preferably in HW, but otherwise in SW if needed).
>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Not according to [RFC
>>>>>>>>>>>>>>>>>>>>>>>>>> 791](https://tools.ietf.org/html/rfc791):
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>>>>>>>>>>>>> The Header Checksum provides a verification that
>>>>>>>>>>>>>>>>>>>>>>>>>> the information used
>>>>>>>>>>>>>>>>>>>>>>>>>> in processing internet datagram has been
>>>>>>>>>>>>>>>>>>>>>>>>>> transmitted correctly. The
>>>>>>>>>>>>>>>>>>>>>>>>>> data may contain errors. If the header checksum
>>>>>>>>>>>>>>>>>>>>>>>>>> fails, the internet
>>>>>>>>>>>>>>>>>>>>>>>>>> datagram is discarded at once by the entity which
>>>>>>>>>>>>>>>>>>>>>>>>>> detects the error.
>>>>>>>>>>>>>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> This requirement is independent of whether or not IP
>>>>>>>>>>>>>>>>>>>>>>>>>> options exist.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Not easily for IPv6, the fragmentation extension
>>>>>>>>>>>>>>>>>>>>>>>>>>> header may be behind a list of other extension
>>>>>>>>>>>>>>>>>>>>>>>>>>> headers. Also it does not make sense to ask L4
>>>>>>>>>>>>>>>>>>>>>>>>>>> checksum for a packet that it cannot be done.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Usually even HW assisted checksum insertion is
>>>>>>>>>>>>>>>>>>>>>>>>>>> ordered by SW on per packet basis. So, if
>>>>>>>>>>>>>>>>>>>>>>>>>>> application does not order correctly, ODP would
>>>>>>>>>>>>>>>>>>>>>>>>>>> need to parse packet and find out if it can be
>>>>>>>>>>>>>>>>>>>>>>>>>>> ordered or not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> L4 check includes fields from IP header. If the IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>> header is not in basic form (has
>>>>>>>>>>>>>>>>>>>>>>>>>>>> options/extensions) HW may not be able to do the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> L4 checksum check.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Basic IP packets checksum checking is a MUST,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> support for options is a MAY.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We don't want to force every implementation to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> check also packets with IP options, since not all
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HW can do it. User finds out if the check was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> done from the packet.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not in this patch, since statistics are defined
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to work as RFCs specify. We don't want to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> redefine how packet_io_stats_t works in here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK and UNKNOWN are the most common cases: OK
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when checking is enabled, UNKNOWN when checking
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disabled. E.g. a router would not need check L4
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checksum, so IPv4 check would be on, but all L4
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checksum checks off.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Initialization is more robust with UNKNOWN ==
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0. Odp-linux would save these along the other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packet flags (init would be flags.all_bits =
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0). On the other hand, HW specific
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation may not store this enum
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anywhere, but directly mask HW specific packet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> descriptor flags to produce the status. In that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case, the values do not matter too much.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can't the interface detect the IPfrag itself?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does this effect IPsec inline output
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fragmentation support?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> L4 checksums being skipped for IP fragments
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is normal, but why the caveat about IP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> options or IPv6 extension headers? A TCP or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UCP checksum is well defined independent of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these L3 considerations.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is the relevance of IP options to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checksum processing? These two are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> orthogonal.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Worth mentioning anything about statistics
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here? Presumably such drops are accumulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since ODP_PACKET_CHKSUM_OK is the most
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> likely case, wouldn't it be better to use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0 for that enum? In almost all cases HW is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> going to "do the right thing" so SW should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only need to initialize this to something
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> else if that's not the case.
https://github.com/Linaro/odp/pull/167#discussion_r138285610
updated_at 2017-09-12 08:41:54
