[dpdk-dev] [PATCH 1/3] security: support pdcp protocol
Joseph, Anoob
Anoob.Joseph at caviumnetworks.com
Tue Oct 9 13:38:42 CEST 2018
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
More information about the dev
mailing list