> > 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
