[dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing

Ananyev, Konstantin konstantin.ananyev at intel.com
Mon Sep 24 12:51:57 CEST 2018


Hi Akhil,

> 
> Hi Konstantin,
> 
> On 9/18/2018 6:12 PM, Ananyev, Konstantin wrote:
> >>> I am not saying this should be the ONLY way to do as it does not work
> >>> very well with non NPU/FPGA class of SoC.
> >>>
> >>> So how about making the proposed IPSec library as plugin/driver to
> >>> rte_security.
> >> As I mentioned above, I don't think that pushing whole IPSec data-path into rte_security
> >> is the best possible approach.
> >> Though I probably understand your concern:
> >> In RFC code we always do whole prepare/process in SW (attach/remove ESP headers/trailers, so paddings etc.),
> >> i.e. right now only device types: RTE_SECURITY_ACTION_TYPE_NONE and RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO are covered.
> >> Though there are devices where most of prepare/process can be done in HW
> >> (RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL/RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL),
> >> plus in future could be devices where prepare/process would be split between HW/SW in a custom way.
> >> Is that so?
> >> To address that issue I suppose we can do:
> >> 1. Add support for RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
> >>      security devices into ipsec.
> >>      We planned to do it anyway, just don't have it done yet.
> >> 2. For custom case - introduce RTE_SECURITY_ACTION_TYPE_INLINE_CUSTOM and
> RTE_SECURITY_ACTION_TYPE_LOOKASIDE_CUSTOM
> >>      and add into rte_security_ops   new functions:
> >>      uint16_t lookaside_prepare(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t
> num);
> >>      uint16_t lookaside_process(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t
> num);
> >>      uint16_t inline_process(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num);
> >>      So for custom HW, PMD can overwrite normal prepare/process behavior.
> >>
> > Actually  after another thought:
> > My previous assumption (probably wrong one) was that for both
> > RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
> > devices can do whole data-path ipsec processing totally in HW - no need for any SW support (except init/config).
> > Now looking at dpaa and dpaa2 devices (the only ones that supports RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL right now)
> > I am not so sure about that - looks like some SW help might be needed for replay window updates, etc.
> > Hemant, Shreyansh - can you guys confirm what is expected from RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL devices
> > (HW/SW roses/responsibilities)?
> > About RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL  - I didn't find any driver inside DPDK source tree that does support that
> capability.
> > So my question is there any devices/drivers that do support it?
> > If so, where could source code could be found, and what are HW/SW roles/responsibilities for that type of devices?
> > Konstantin
> >
> >
> In case of LOOKASIDE, the protocol errors like antireplay and sequence
> number overflow shall be the responsibility of either PMD or the HW.
> It should notify the application that the error has occurred and
> application need to decide what it needs to decide next.

Ok, thanks for clarification.
Just to confirm -  do we have a defined way for it right now in rte_security?

> 
> As Jerin said in other email, the roles/responsibility of the PMD in
> case of inline proto and lookaside case, nothing much is required from
> the application to do any processing for ipsec.
> 
> As per my understanding, the proposed RFC is to make the application
> code cleaner for  the protocol processing.

Yes, unified data-path API is definitely one of the main goals. 

> 1. For inline proto and lookaside there won't be any change in the data
> path. The main changes would be in the control path.

Yes, from your and Jerin description data-path processing looks
really lightweight for these cases.
For control path - there is no much change, user would have to call 
rte_ipsec_sa_init() to start using given SA.

> 
> 2. But in case of inline crypto and RTE_SECURITY_ACTION_TYPE_NONE, the
> protocol processing will be done in the library and there would be
> changes in both control and data path.

Yes.

> 
> As the rte_security currently provide generic APIs for control path only
> and we may have it expanded for protocol specific datapath processing.
> So for the application, working with inline crypto/ inline proto would
> be quite similar and it won't need to do some extra processing for
> inline crypto.
> Same will be the case for RTE_SECURITY_ACTION_TYPE_NONE and lookaside.
> 
> We may have the protocol specific APIs reside inside the rte_security
> and we can use either the crypto/net PMD underneath it.

As I understand, you suggest instead of introducing new library,
introduce similar data-path functions inside rte_security.
Probably something like:

uint16_t rte_security_process(struct rte_security_session *s, struct rte_mbuf *mb[], uint16_t num);
uint16_t rte_security_crypto_prepare(struct rte_ipsec_sa *sa, struct rte_mbuf *mb[], 
                                                                      struct rte_crypto_op *cop[], uint16_t num);
...
Is that correct?

I thought about that approach too, and indeed from one side it looks cleaner and easier
to customize - each of these functions would just call related function inside rte_security_ops.
The problem with that approach - it would mean that each SA would be able to work with one
device only.
So if someone needs an SA that could be processed by multiple cores and multiple crypto-devices
in parallel such approach wouldn’t fit.
That was the main reason to keep rte_security as it is right now and go ahead with new library.
One thing that worries me -  do we need a way to share SQN and replay window information
between rte_security and upper layer (rte_ipsec)?
If 'no', then ok, if 'yes' then probably we need to discuss how to do it now?

> 
> Moving the SPD lookup inside the ipsec library may not be beneficial in
> terms of performance as well as configurability for the application. It
> would just be based on the rss hash.

If SPD c be done completely in HW - that's fine.
I just don't think there are many devices these days that wouldn't require
any SW intervention for SPD lookup, and I think RSS would be enough here 
(though flow-director might be).
As I said before, my thought was that might be ACL library would be enough
here as SW fallback, but if people think we need a special API/implementation
for it - that's ok by me too.
Konstantin


More information about the dev mailing list