Re: [dpdk-dev] [PATCH 1/3] security: support pdcp protocol

["Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com>]

Hi Akhil,

Please see inline.

Thanks,
Anoob
On 08-10-2018 15:19, Akhil Goyal wrote:
> External Email
>
> Hi Anoob,
>>>>> @@ -494,6 +553,23 @@ IPsec related configuration parameters are
>>>>> defined in ``rte_security_ipsec_xform
>>>>>            /**< Tunnel parameters, NULL for transport mode */
>>>>>        };
>>>>> +PDCP related configuration parameters are defined in
>>>>> ``rte_security_pdcp_xform``
>>>>> +
>>>>> +.. code-block:: c
>>>>> +
>>>>> +    struct rte_security_pdcp_xform {
>>>>> +        int8_t bearer; /**< PDCP bearer ID */
>>>>> +        enum rte_security_pdcp_domain domain;
>>>>> +        /** < PDCP mode of operation: Control or data */
>>>>> +        enum rte_security_pdcp_direction pkt_dir;
>>>>> +        /**< PDCP Frame Direction 0:UL 1:DL */
>>>>> +        enum rte_security_pdcp_sn_size sn_size;
>>>>> +        /**< Sequence number size, 5/7/12/15 */
>>>>> +        int8_t hfn_ovd; /**< Overwrite HFN per operation */
>>>>> +        uint32_t hfn;  /**< Hyper Frame Number */
>>>>> +        uint32_t hfn_threshold;        /**< HFN Threashold for key
>>>>> renegotiation */
>>>>> +    };
>>>>> +
>>>> [Anoob] PDCP packet ordering should be both a capability and a 
>>>> setting.
>>>> HFN will be incremented overtime and starts at 0. So why is it part of
>>>> the xform?
>>>
>>> The Security accelerators may assume packet in order. Latest PDCP TS
>>> suggest to do de-Ciphering before re-Ordering the Rx PDCP PDUs. In this
>>> situation, the accelerator may use wrong HFN value. The PDCP 
>>> application
>>> can provide the appropriate HFN value along with PDU to the security
>>> accelerator.
>>>
>> So what is the expectation with regards to ordering? Would PDCP know
>> the order or is it unaware of the order?
>> If implementation of this Spec knows the order of packets(which is
>> implied by the "In order delivery and Duplicate detection
>> Sequence Numbering" statement in the PDCP flow diagram), then there
>> should be no need to override the
>> HFN. If the implementation does not know the order of packets, then
>> the flow diagram should be corrected.
>> Also, is implementation expected to support ordered delivery and
>> duplicate detection. Perhaps it should be
>> a capability or 2.
> This patchset is basically talking about full protocol offload with look
> aside accelerators.
> And when we are talking about full protocol offload, all protocol
> related stuff like ordering, headers etc.
> needs to be handled by the HW/driver.
> So the expectation is driver/HW should be able to perform in order
> delivery and detect duplicates.
How will errors in these situations be reported to the application - if 
packets are not in order or if a duplicate is detected - how should 
driver report it?
Is the driver/HW expected to correct the order OR is the behaviour 
limited to detection of out-of-order? In order to correct the order, the 
driver/HW will need to accumulate packets. Is that really the 
expectation of this specification
> If somebody have support for PDCP in the hardware, we can add
> capabilities as per the specific requirements.
> In v2/v3 I have removed the hfn_override. Will add it later when it will
> be supported.
>
>
> Thanks,
> Akhil