Maybe it's better to add this into packet pool parameters. Usage of build time
config macros should be minimized in the future.
/** User area size in bytes. Specify as 0 if no user
area is needed. */
uint32_t uarea_size;
/** Static user area data.
* 0: User area data can be overwritten while in pool (between free
and alloc calls).
* 1: User area data is static. System will never overwrite the area.
* Entire area is initialized to zero in pool creation.
* Default is 0.
*/
int uarea_static;
Every platform should be able to provided static area, but the performance may
degrade due to extra indirection etc. Zero initialization would help user to
tell if the area has valid data or not. I'd like to avoid callbacks from pool
create to keep it simple.
-Petri
> -----Original Message-----
> From: ext Zoltan Kiss [mailto:[email protected]]
> Sent: Thursday, July 02, 2015 7:43 PM
> To: [email protected]
> Cc: [email protected]; [email protected];
> Savolainen, Petri (Nokia - FI/Espoo)
> Subject: [API-NEXT PATCH RFC] api: packet: add optional persistent
> metadata
>
> This requirement came from ODP-OVS: it handles buffers through 'struct
> ofpbuf'
> (in upstream it became 'struct dp_packet'), and they can be non-ODP
> buffers as
> well. Therefore after receiving a packet currently we have to reset three
> fields in it: 'source' (to ODP), 'allocated' (segment size, OVS doesn't
> support
> multiple segments in this struct) and 'odp_pkt' (points to the containing
> odp_packet_t)
> The native DPDK implementation takes advantage of the fact that the buffer
> and
> user metadata area, where this struct is stored is allocated during pool
> creation time, therefore it initializes it to static values at startup.
> When
> I've tried this behaviour with ODP-DPDK, the performance increased from
> ~12.7
> to ~12.9 Mpp. That's only ~%1.6 increase, but in other words it's ~%17 of
> the
> gap between the current and OVS-DPDK performance (13.9 Mpp)
> I would like a propose an optional feature where the implementation can
> signal
> if it guarantees this behaviour. I think most implementations would
> preallocate these areas to achieve good performance, but e.g. linux-
> generic
> does not AFAIK.
>
> Signed-off-by: Zoltan Kiss <[email protected]>
> ---
> include/odp/api/config.h | 10 ++++++++++
> include/odp/api/packet.h | 4 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/config.h b/include/odp/api/config.h
> index 91ea34e..d48030e 100644
> --- a/include/odp/api/config.h
> +++ b/include/odp/api/config.h
> @@ -121,6 +121,16 @@ extern "C" {
> */
> #define ODP_CONFIG_PACKET_BUF_LEN_MAX (ODP_CONFIG_PACKET_SEG_LEN_MIN*6)
>
> +/**
> + * Guarantee that user metadata is allocated during pool creation
> + *
> + * If this parameter is 1, applications can avoid reseting persistent
> parts of
> + * the area returned by odp_packet_user_area() by setting them once,
> after pool
> + * creation. It will keep its content between odp_packet_free() and
> + * odp_packet_alloc().
> + */
> +#define ODP_CONFIG_PACKET_PERSISTENT_MD 0
> +
> /** Maximum number of shared memory blocks.
> *
> * This the the number of separate SHM areas that can be reserved
> concurrently
> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> index 91a124a..d7aeb95 100644
> --- a/include/odp/api/packet.h
> +++ b/include/odp/api/packet.h
> @@ -448,7 +448,9 @@ void odp_packet_user_ptr_set(odp_packet_t pkt, const
> void *ctx);
> * User area address
> *
> * Each packet has an area for user data. Size of the area is fixed and
> defined
> - * in packet pool parameters.
> + * in packet pool parameters. If ODP_CONFIG_PACKET_PERSISTENT_MD is 1,
> this
> + * area is allocated during pool creation, and keep its content between
> + * odp_packet_free() and odp_packet_alloc().
> *
> * @param pkt Packet handle
> *
> --
> 1.9.1
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
