On 8/31/2017 2:14 PM, Thomas Monjalon wrote:
31/08/2017 12:52, Akhil Goyal:
On 8/31/2017 3:36 PM, Thomas Monjalon wrote:
31/08/2017 11:37, Akhil Goyal:
On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
25/07/2017 13:21, Akhil Goyal:
2. Ipsec inline(RTE_SECURITY_SESS_ETH_INLINE_CRYPTO) - This is when the
crypto operations are performed by ethernet device instead of crypto
device. This is also without protocol knowledge inside the ethernet device
If the ethernet device can act as a crypto device, this function
should be offered via the cryptodev interface.
yes this could be thought of but the intent was to keep cryptodev and
ethdev separate, as this would create confusion and will become
difficult to manage.
I think the reverse: it is confusing to do crypto operations through
ethdev interface.
If a device can do "standalone crypto" and networking, it should appear as
2 different ports in my opinion.
How is it different from mode RTE_SECURITY_SESS_NONE?
In RTE_SECURITY_SESS_NONE - crypto device is used for crypto operations.
In RTE_SECURITY_SESS_ETH_INLINE_CRYPTO - ethernet device is used for
crypto operations.
For details of the data path of this mode, refer to the covernote of RFC
patch from Boris.
http://dpdk.org/ml/archives/dev/2017-July/070793.html
For implementation of this mode, see patches from Radu,
http://dpdk.org/ml/archives/dev/2017-August/073587.html
Boris RFC uses rte_flow.
Radu implementation does not use rte_flow.
So I still don't understand the big picture.
Boris asked the question and had no answer.
I'll answer here: it was an omission from my side; v2 of the will
include rte_flow usage, derived from Boris RFC.
Is there direct Rx/Tx involved in this mode?
No the packet will come to the application and will add/remove relevant
headers and then send the packet to the appropriate eth dev after route
lookup.
3. full protocol offload(RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD) - This is
same as 2 but with protocol support in the ethernet device.
Is there direct Rx/Tx in RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD?
No, there should not be direct rx/tx as the application will do route
lookup and send the packet to relevant ethernet interface.
4. look aside protocol offload(RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD) -
This is same as 1 but with protocol support in crypto device.
Who is responsible for Rx/Tx in RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD?
The packet is returned back to the application as in the case of non
protocol offload. But the application doesnt need to take care of the
headers and other protocol specifics. It just need to forward the packet
to the relevent eth dev after route lookup.
Please refer to RFC v2 of the proposal it has more details in the header
file rte_security.h and the implementation using the ipsec-secgw
application.
http://dpdk.org/ml/archives/dev/2017-August/072900.html
So there is no direct Rx/Tx in any mode?
What is the point of using an ethdev port if there is no Rx/Tx?
[...]
The application can decide using the below action types
enum rte_security_session_action_type {
RTE_SECURITY_SESS_ETH_INLINE_CRYPTO,
/**< Crypto operations are performed by Network interface */
In this mode, the ethdev port does the same thing as a crypto port?
not exactly everything. In this mode, only cipher and auth operations
are performed by the eth device. No intelligence about the protocol is
done. This is similar to what the current implementation do with the
crypto device(Non protocol offload).
Are you saying no but yes?
I say "ethdev port does the same thing as a crypto port"
You say "similar to what the current implementation do with the crypto device"
This is said so because the crypto device may also support protocol offload.
RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD,
/**< Crypto operations with protocol support are performed
* by Network/ethernet device.
*/
RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD,
/**< Crypto operations with protocol support are performed
* by Crypto device.
*/
I guess the difference between ETH_PROTO_OFFLOAD and CRYPTO_PROTO_OFFLOAD
is that we must re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?
yes
OK
Who is responsible to re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?
Application will do the forwarding after route lookup
RTE_SECURITY_SESS_NONE
/**< Non protocol offload. Application need to manage everything */
};
What RTE_SECURITY_SESS_NONE does? It is said to be implemented above.
It is non protocol offload mentioned above.
How is it different from using cryptodev?
No it is not different. It is just to mention that there is no security
session involved and the application will use the cryptodev.
As far as I understand, my vote is a NACK for the current proposal.
