Hi Konstantin,
On 10/1/2018 2:30 AM, Ananyev, Konstantin wrote:
Hi Akhil,
Hi Konstantin,
On 9/24/2018 4:21 PM, Ananyev, Konstantin wrote:
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 of now, there are no macros defined for antireplay/seq. no. overflow
errors in crypto errors(rte_crypto_op_status), but it will be added soon.
For inline cases, ipsec-secgw application gets error notification via
rte_eth_event.
Ok.
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?
"rte_security_process_ipsec" and "rte_security_crypto_prepare_ipsec" will be
better.
We can have such APIs for other protocols as well.
Also, we should leave the existing functionality as is and we should let the
user decide whether
it needs to manage the ipsec on it's own or with the new APIs.
There are no plans to void any existing API.
If the user has working code that uses rte_crytpodev/rte_security directly and
wants to keep it,
that's fine.
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.
One SA should be processed by a single core or else we need to have an
event based application which support ordered queues,
because if we process packets of single SA on multiple cores, then
packets will get re-ordered and we will get the anti-replay late errors
on decap side.
I suppose in some cases one core would be enough to handle SA traffic,
for some not, as I said before, I think it should be configurable.
Of course for MT case some entity that would guarantee proper ordering
for final packet processing would be needed.
It could be some eventdev, or SW FIFO queue, or something else.
And if we have event based solution, then the scheduler will be able to
handle the load balancing accordingly.
Didn't understand that sentence.
I mean the event device will be able to handle that which has an inbuilt
scheduler in it for balancing the load of single SA,
and if the queues are ordered and it support order restoration, then it
will be able to maintain the ordering. And for that
you would not have to bother about giving the same SA to different
cryptodevs on multi cores.
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?
anti-replay window size shall be a parameter in ipsec_xform, which shall
be added.
And the error notification
- in case of using crypto, then use rte_crypto_op_status
- in case of inline cases, then use rte_eth_event callbacks.
I don't see rte_ipsec needs to take care of that in your initial approach.
However, if you plan to include session reset inside rte_ipsec, then you
may need that inside the rte_ipsec.
I am not talking rte_ipsec, my concern here is rte_security.
Suppose you need to switch from device that can do inline_proto to the device
that doesn't.
In what use case you would need such switching?
Right now the only way - renegotiate all SAs that were handled by inline_proto
device
(because there is no way to retrieve from rte_security device SQN information).
Renegotiation should work, but it looks like quite expensive approach.
This will be only for the first packet.
If rte_security would have a way to share its SQN status with SW, then I think
it would
be possible to do such switch without SA termination.
what kind of SQN status you are looking for? overflow? If yes,
application need to re-negotiate the session,
which will be done periodically anyways.
Again with such info available - load-balancing for the same SA on multiple
devices
might be possible.
Konstantin
