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
