RE: [PATCH v2] doc: announce rte_ipsec API changes

[Aakash Sasidharan <asasidharan@marvell.com>]

> -----Original Message-----
> From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> Sent: Tuesday, July 23, 2024 9:35 PM
> To: Aakash Sasidharan <asasidharan@marvell.com>
> Cc: Akhil Goyal <gakhil@marvell.com>; Jerin Jacob <jerinj@marvell.com>;
> Anoob Joseph <anoobj@marvell.com>; Vidya Sagar Velumuri
> <vvelumuri@marvell.com>; dev@dpdk.org; konstantin.v.ananyev@yandex.ru;
> vladimir.medvedkin@intel.com
> Subject: [EXTERNAL] RE: [PATCH v2] doc: announce rte_ipsec API changes
> 
> Hi,
> 
> > In case of event mode operations where event device can help in atomic
> > sequence number increment across cores, sequence number need to be
> > provided by the application instead of being updated in rte_ipsec or
> > the PMD. To support this, a new flag
> > ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE``
> > will be added to disable sequence number update inside IPsec library
> > and the API rte_ipsec_pkt_crypto_prepare will be extended to include
> > ``sqn`` as an additional parameter to specify sequence number to be
> > used for IPsec from the application.
> 
> Could you probably elaborate a bit more:
> Why such change is necessary for event-dev mode, what exactly will be
> affected in librte_ipsec (would it be for outbound mode, or both), etc.
> 

[Aakash] When using eventdev, it is possible to have multiple cores process packets from the same flow at the same time, but still have ordering maintained.

Sequence for IPsec would be like below,
1. Ethdev Rx computes flow hash and submits packets to an ORDERED eventdev queue.
    One flow would always hit one event dev queue.
    One eventdev queue can be attached to multiple eventdev ports.
2. Lcores receives packets via these eventdev ports.
    Lcores can now process the packets from the same flow in parallel.
3. Lcores submit the packets to an ATOMIC queue
    This is needed as IPsec seq no update needs to be done atomically.
4. After seq no update, packets are moved to ORDERED queue.
    Lcores can now processes the packets in parallel again.
5. During Tx, eventdev ensures packet ordering based on ORDERED queue.

Since lib IPsec takes care of sequence number assignment, complete rte_ipsec_pkt_crypto_prepare() routine need to be made as ATOMIC stage.
But apart from seq no update, rest of the operations can be done in parallel.

In addition, we are also looking at another use case when a set of packets from a session can be IPsec processed by rte_security device and some packets from the same session would need to be SW processed with lib IPsec. Here again the sequence number assignment would need to occur at central place so that sequence number is not repeated.

Initially we are looking at outbound only. But similar kind of use case would be applicable for inbound also.

> >
> > Signed-off-by: Aakash Sasidharan <asasidharan@marvell.com>
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 6948641ff6..bc1d93cca7 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -133,6 +133,13 @@ Deprecation Notices
> >    Since these functions are not called directly by the application,
> >    the API remains unaffected.
> >
> > +* ipsec: The rte_ipsec library is updated to support sequence number
> > +provided
> > +  by application. A new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE``
> > +is introduced
> > +  to disable sequence number assignment in lib IPsec.
> > +  The API rte_ipsec_pkt_crypto_prepare is extended to include ``sqn``
> > +as an
> > +  additional parameter allowing application to specify the sequence
> > +number to be
> > +  used for the IPsec operation.
> > +
> >  * pipeline: The pipeline library legacy API (functions rte_pipeline_*)
> >    will be deprecated and subsequently removed in DPDK 24.11 release.
> >    Before this, the new pipeline library API (functions
> > rte_swx_pipeline_*)
> > --
> > 2.25.1