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

[Akhil Goyal]

On 10/9/2018 5:08 PM, Joseph, Anoob wrote:
> 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
I have added a setting in xform and capability for in-order and 
duplicate packet detection.
So if the capability is there in hardware to do such processing then it 
will do that and report error
in crypto status and if the capability is not there then application 
will be responsible for handling such cases.
I hope this would answer your query.

>> 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
>