Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:
platform/linux-generic/odp_ipsec.c
@@ -676,23 +676,36 @@ static ipsec_sa_t *ipsec_out_single(odp_packet_t pkt,
ip_data_len +
ipsec_sa->icv_len;
- if (ipsec_sa->esp_iv_len) {
+ if (ipsec_sa->use_counter_iv) {
+ uint64_t ctr;
+
+ /* Both GCM and CTR use 8-bit counters */
+ ODP_ASSERT(sizeof(ctr) == ipsec_sa->esp_iv_len);
+
+ ctr = odp_atomic_fetch_add_u64(&ipsec_sa->out.counter,
+ 1);
+ /* Check for overrun */
+ if (ctr == 0)
+ goto out;
+
Comment:
This test is unnecessary as you're not going to overflow a 64-bit counter.
> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> This test is going to need revision since the actual CoS is selected as a
> result of filtering the decrypted packet through PMRs that don't exist in
> this version of the test. Another reason to make pipeline support its own PR.
>
> The test we'd want is
>
> - Create a couple of CoS and associated queue objects.
> - Create PMRs that filter packets into these CoSes.
> - Create plaintext packets that will match the PMRs defined.
> - Encrypt these packets via `odp_ipsec_out()`
> - Now decrypt them via `odp_ipsec_in_enq()` with pipelining enabled and
> verify that the results show up on the expected queue based on the previously
> defined PMRs.
>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Pipelining isn't about sending the result to an alternate queue that's known
>> ahead of time, but rather about sending the result to the
>> `cls_classify_packet()` function so that classification can be run against
>> the decrypted packet and PMRs can filter it into the correct CoS (and
>> associated queue) that is to receive the packet.
>>
>> This is likely to be a sufficiently large change in itself that it may be
>> better to be its own PR, in which case this can be pulled from the rest of
>> this PR so that the other changes can be merged first.
>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Not urgent, but at some point we should look at [RFC
>>> 6479](https://tools.ietf.org/html/rfc6479) to handle larger windows needed
>>> for large multi-core systems and to do this more efficiently.
>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>> It seems inefficient to incur those two atomic loads on every call. How
>>>> about:
>>>> ```
>>>> if (ipsec_sa->hard_limit_bytes > 0 &&
>>>> odp_atomic_load_u64(&ipsec_sa->bytes) > ipsec_sa->hard_limit_bytes)
>>>> etc.
>>>> ```
https://github.com/Linaro/odp/pull/243#discussion_r150423934
updated_at 2017-11-12 22:06:14
