will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
``rte_mbuf.ol_flags`` field. The driver would also set device-specific
-metadata in ``rte_mbuf.udata64`` field. This will allow the application
-to identify the security processing done on the packet.
+metadata in ``RTE_SECURITY_DYNFIELD_NAME`` field.
+This will allow the application to identify the security processing
+done on the packet.
.. note::
The Security framework provides APIs to create and free sessions for crypto/ethernet
devices, where sessions are mempool objects. It is the application's responsibility
-to create and manage the session mempools. The mempool object size should be able to
-accommodate the driver's private data of security session.
+to create and manage two session mempools - one for session and other for session
+private data. The private session data mempool object size should be able to
+accommodate the driver's private data of security session. The application can get
+the size of session private data using API ``rte_security_session_get_size``.
+And the session mempool object size should be enough to accommodate
+``rte_security_session``.
Once the session mempools have been created, ``rte_security_session_create()``
is used to allocate and initialize a session for the required crypto/ethernet device.
.. note::
- In case of inline processed packets, ``rte_mbuf.udata64`` field would be
- used by the driver to relay information on the security processing
+ In case of inline processed packets, ``RTE_SECURITY_DYNFIELD_NAME`` field
+ would be used by the driver to relay information on the security processing
associated with the packet. In ingress, the driver would set this in Rx
path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
similar operation. The application is expected not to modify the field