bogdanPricope 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:
Fine.
Implementation for dpdk pktio?
> None(bogdanPricope) wrote:
> 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.
>> bogdanPricope 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.
>>> None(bogdanPricope) 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.
>>>> None(bogdanPricope) 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).
>>>>> None(bogdanPricope) 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.
>>>>>> None(bogdanPricope) 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.
>>>>>>> None(bogdanPricope) 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.
>>>>>>>
>>>>>>>> bogdanPricope 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.
>>>>>>>>> bogdanPricope 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).
>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>> bogdanPricope 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.
>>>>>>>>>>>>> None(bogdanPricope) 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?
>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>> bogdanPricope 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);
>>>>>>>>>>>>>>>>> bogdanPricope 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.
>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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).
>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) wrote:
>>>>>>>>>>>>>>>>>>>>>>> OK
>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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).
>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can't the interface detect the IPfrag itself?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How does this effect IPsec inline output
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fragmentation support?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is the relevance of IP options to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> checksum processing? These two are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> orthogonal.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Worth mentioning anything about statistics
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here? Presumably such drops are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accumulated there.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> None(bogdanPricope) 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_r138314543
updated_at 2017-09-12 10:57:48
