Hi Akhil,
On 15-10-2018 18:33, Akhil Goyal wrote:
> External Email
>
> 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.
Seems good.
>
>>> 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
>>
>
