Lets bring it up in the call, looks like there are issues of grouping,
naming and how many APIs there are to retrieve the data.
On 22 July 2015 at 05:31, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> I would add only one odp api call to fetch platform config.
>
> Like
>
> int odp_get_platform_config(struct platform_config *config);
>
> where:
> struct platform_config {
> struct {
> <some queue settings>
> } queue;
> struct {
> <some pool settings>
> } pool;
> ....
> }
>
>
> One function instead 20 others for each layer it better.
>
> Maxim.
>
> On 07/22/15 00:36, Bill Fischofer wrote:
>
>> I think it's better to have these configuration limits in one place than
>> to find them scattered all over. That was why they had ODP_CONFIG_xxx
>> prefixes in the first place.
>>
>> Perhaps worth discussing in tomorrow's ARCH call, however I don't think
>> we have critical architectural "mass" given the Summer holidays.
>>
>> On Tue, Jul 21, 2015 at 4:27 PM, Mike Holmes <mike.hol...@linaro.org
>> <mailto:mike.hol...@linaro.org>> wrote:
>>
>>
>>
>> On 21 July 2015 at 16:54, Bill Fischofer
>> <bill.fischo...@linaro.org <mailto:bill.fischo...@linaro.org>> wrote:
>>
>> One of the principles of ODP APIs is that they do not
>> unnecessarily impose structure on the implementation. So APIs
>> in general do not specify or return aggregate information. A
>> static table might seem "efficient" however consider an
>> implementation where things like pool counts were exposed (by
>> HW) as a special purpose register (SPR) designed to be read.
>> Forcing these individual limits into an artificial aggregate
>> would not be implementation-friendly.
>>
>> Implementations can easily adapt the linux-generic files
>> as-is, simply replacing the internal #defines with their own
>> values, or else implementing the inlined access functions as
>> makes the most sense. As I mentioned, I believe the #defines
>> should be deprecated in favor of the APIs for anything except
>> internal use. This would simply mean that the tests and
>> examples that currently use them for dimensioning arrays would
>> need to do so on a dynamic basis.
>>
>> The idea behind encouraging the use of APIs rather than
>> #defines for this sort of information is both for consistency
>> with the rest of ODP, as well as to better support future ABI
>> requirements since static #defines are not runtime portable.
>>
>>
>> Aiming at ABI compliance is worthwhile a reason to convert them to
>> functions.
>>
>> However then the notion of a big fat config file loses value for
>> me because it will become a complected mixture of API calls for
>> un-associated values, that only made sense if they were compile
>> time defines I think.
>>
>> Would it not be better to associate this data with their modules,
>> that is where you would expect to find these answers and then a
>> common pattern emerges for the naming also. The current naming
>> does not describe the data returned in a number of cases.
>>
>> /**
>> * Maximum number of pools
>> + * @return The maximum number of pools supported by this platform
>> */
>> -#define ODP_CONFIG_POOLS 16
>> +int odp_config_pools(void); ------> +int odp_pool_max(void)
>>
>> /**
>> * Maximum number of queues
>> + * @return The maximum number of queues supported by this platform
>> */
>> -#define ODP_CONFIG_QUEUES 1024
>> +int odp_config_queues(void); -------> +int odp_queue_max(void);
>>
>>
>> On Tue, Jul 21, 2015 at 12:53 PM, Nicolas Morey Chaisemartin
>> <nmo...@kalray.eu <mailto:nmo...@kalray.eu>> wrote:
>>
>>
>>
>>
>> Nicolas Morey Chaisemartin KALRAY SA
>> www.kalray.eu <http://www.kalray.eu>
>> Phone : +33 6 42 46 68 87
>> <tel:%2B33%206%2042%2046%2068%2087>
>> nmo...@kalray.eu <mailto:nmo...@kalray.eu> Follow us 86
>> rue de Paris
>> 91400 Orsay FRANCE
>> 445 rue Lavoisier
>> 38330 Montbonnot FRANCE This message contains information
>> that may be privileged or confidential and is the property
>> of the KALRAY SA. It is intended only for the person to
>> whom it is addressed. If you are not the intended
>> recipient, you are not authorized to print, retain, copy,
>> disseminate, distribute, or use this
>> ----- Mike Holmes <mike.hol...@linaro.org
>> <mailto:mike.hol...@linaro.org>> wrote:
>> > On 21 July 2015 at 13:01, Bill Fischofer <
>> bill.fischo...@linaro.org
>> <mailto:bill.fischo...@linaro.org>> wrote:
>> >
>> > > Well, we want to encourage applications to make use of
>> the APIs rather
>> > > than the #defines since that provides a more flexible
>> interface and is more
>> > > consistent with the rest of ODP. I originally thought
>> to rename the
>> > > #defines from ODP_CONFIG_xxx to _ODP_CONFIG_xxx to
>> emphasize that the
>> > > #defines are intended for internal rather than
>> external use, however a
>> > > number of our examples reference them directly for
>> things like array
>> > > dimensioning.
>> > >
>> > > Worth discussing this further. Any others have input
>> to this?
>> > >
>> >
>> > Thinking out loud if we go down this route.
>> >
>> > Given that the new API is essential returning data from
>> a static table of
>> > defines describing the limits of the platform I feel
>> like it should be
>> > defined as a static table by the platform.
>> > I think then the code can be reused as the access
>> functions all become just
>> > indexes into the table defined per platform, it feels
>> like it contains the
>> > differences per platform more cleanly.
>> >
>>
>> I like this idea. Less code to rewrite for other platforms.
>>
>> >
>> > >
>> > > On Tue, Jul 21, 2015 at 11:57 AM, Nicolas
>> Morey-Chaisemartin <
>> > > nmo...@kalray.eu <mailto:nmo...@kalray.eu>> wrote:
>> > >
>> > >> They currently do not need to edit
>> include/odp/api/config.h.
>> > >> I ran into the issue yesterday and realized that you
>> can override those
>> > >> settings from platform/<name>/include/odp/config.h
>> already.
>> > >> Because users are supposed to include odp/<name>.h
>> which in turn includes
>> > >> odp/api/<name.h>, it is quite simple to override
>> global settings this way.
>> > >>
>> > >> I'm not against this patch although it's a bit of
>> shame that every
>> > >> platform will have to duplicate all the file
>> (including static inline
>> > >> functions) to change the define value.
>> > >>
>> > >> Nicolas
>> > >>
>> > >> On 07/21/2015 06:51 PM, Bill Fischofer wrote:
>> > >>
>> > >> The problem is twofold:
>> > >>
>> > >> 1. include/odp/api/ is supposed to contain pubic APIs
>> that each
>> > >> platform implements. As such, having linux-generic
>> #defines in the
>> > >> config.h file in this location is inconsistent. So
>> this patch introduces
>> > >> actual APIs that are platform independent. So
>> odp_config_pools() tells you
>> > >> the number of pools on this platform.
>> > >>
>> > >> 2. At the same time, some programs use the #defines
>> directly to do
>> > >> things like dimension arrays, so these #defines (as
>> well as the
>> > >> implementations of the public config APIs now live in
>> > >> platform/<name>/include/odp/config.h
>> > >>
>> > >> So no change for applications, however now each
>> platform can easily
>> > >> define their own limits without having to edit the
>> include/odp/api/config.h
>> > >> file.
>> > >>
>> > >> On Tue, Jul 21, 2015 at 11:45 AM, Nicolas
>> Morey-Chaisemartin <
>> > >> <nmo...@kalray.eu
>> <mailto:nmo...@kalray.eu>>nmo...@kalray.eu
>> <mailto:nmo...@kalray.eu>> wrote:
>> > >>
>> > >>> Just for my information, why do we need this?
>> > >>>
>> > >>>
>> > >>> On 07/21/2015 06:42 PM, Bill Fischofer wrote:
>> > >>>
>> > >>> Please ignore this. Resubmitting with proper
>> API-NEXT tag.
>> > >>>
>> > >>> On Tue, Jul 21, 2015 at 11:40 AM, Bill Fischofer <
>> > >>> <bill.fischo...@linaro.org
>> <mailto:bill.fischo...@linaro.org>>bill.fischo...@linaro.org
>> <mailto:bill.fischo...@linaro.org>> wrote:
>> > >>>
>> > >>>> Move platform-specific #defines for limits from the
>> public API to
>> > >>>> the platform directory and add public APIs for each
>> of them.
>> > >>>>
>> > >>>> Signed-off-by: Bill Fischofer <
>> <bill.fischo...@linaro.org <mailto:bill.fischo...@linaro.org
>> >>
>> > >>>> bill.fischo...@linaro.org
>> <mailto:bill.fischo...@linaro.org>>
>>
>>
>> > >>>>
>> > >>>> ---
>> > >>>> include/odp/api/config.h | 61 ++++++-----
>> > >>>> platform/linux-generic/include/odp/config.h | 156
>> > >>>> ++++++++++++++++++++++++++++
>> > >>>> 2 files changed, 192 insertions(+), 25 deletions(-)
>> > >>>>
>> > >>>> diff --git a/include/odp/api/config.h
>> b/include/odp/api/config.h
>> > >>>> index b5c8fdd..a57c76b 100644
>> > >>>> --- a/include/odp/api/config.h
>> > >>>> +++ b/include/odp/api/config.h
>> > >>>> @@ -19,50 +19,58 @@ extern "C" {
>> > >>>> #endif
>> > >>>>
>> > >>>> /** @defgroup odp_config ODP CONFIG
>> > >>>> - * Macro for maximum number of resources in ODP.
>> > >>>> + * Platform-specific configuration limits.
>> > >>>> * @{
>> > >>>> */
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum number of threads
>> > >>>> + * @return The maximum number of threads supported
>> by this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_MAX_THREADS 128
>> > >>>> +int odp_config_max_threads(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum number of pools
>> > >>>> + * @return The maximum number of pools supported
>> by this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_POOLS 16
>> > >>>> +int odp_config_pools(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum number of queues
>> > >>>> + * @return The maximum number of queues supported
>> by this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_QUEUES 1024
>> > >>>> +int odp_config_queues(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Number of scheduling priorities
>> > >>>> + * @return The number of scheduling priorities
>> supported by this
>> > >>>> platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_SCHED_PRIOS 8
>> > >>>> +int odp_config_sched_prios(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum number of packet IO resources
>> > >>>> + * @return The maximum number of packet I/O
>> resources supported by this
>> > >>>> + * platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_PKTIO_ENTRIES 64
>> > >>>> +int odp_config_pktio_entries(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Minimum buffer alignment
>> > >>>> *
>> > >>>> - * This defines the minimum supported buffer
>> alignment. Requests for
>> > >>>> values
>> > >>>> - * below this will be rounded up to this value.
>> > >>>> + * @return The minimum buffer alignment supported
>> by this platform
>> > >>>> + * @note Requests for values below this will be
>> rounded up to this
>> > >>>> value.
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_BUFFER_ALIGN_MIN 16
>> > >>>> +int odp_config_buffer_align_min(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum buffer alignment
>> > >>>> *
>> > >>>> * This defines the maximum supported buffer
>> alignment. Requests for
>> > >>>> values
>> > >>>> * above this will fail.
>> > >>>> + *
>> > >>>> + * @return The maximum buffer alignment supported
>> by this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_BUFFER_ALIGN_MAX (4*1024)
>> > >>>> +int odp_config_buffer_align_max(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Default packet headroom
>> > >>>> @@ -72,11 +80,9 @@ extern "C" {
>> > >>>> * allocated packets. Implementations may reserve a
>> larger than
>> > >>>> minimum headroom
>> > >>>> * size e.g. due to HW or a protocol specific
>> alignment requirement.
>> > >>>> *
>> > >>>> - * @internal In linux-generic implementation:
>> > >>>> - * The default value (66) allows a 1500-byte
>> packet to be received
>> > >>>> into a single
>> > >>>> - * segment with Ethernet offset alignment and room
>> for some header
>> > >>>> expansion.
>> > >>>> + * @return Default packet headroom in bytes
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_PACKET_HEADROOM 66
>> > >>>> +int odp_config_packet_headroom(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Default packet tailroom
>> > >>>> @@ -84,10 +90,11 @@ extern "C" {
>> > >>>> * This defines the minimum number of tailroom bytes
>> that newly
>> > >>>> created packets
>> > >>>> * have by default. The default apply to both ODP
>> packet input and user
>> > >>>> * allocated packets. Implementations are free to
>> add to this as
>> > >>>> desired
>> > >>>> - * without restriction. Note that most
>> implementations will
>> > >>>> automatically
>> > >>>> - * consider any unused portion of the last segment
>> of a packet as
>> > >>>> tailroom
>> > >>>> + * without restriction.
>> > >>>> + *
>> > >>>> + * @return The default packet tailroom in bytes
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_PACKET_TAILROOM 0
>> > >>>> +int odp_config_packet_tailroom(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Minimum packet segment length
>> > >>>> @@ -95,8 +102,10 @@ extern "C" {
>> > >>>> * This defines the minimum packet segment buffer
>> length in bytes. The
>> > >>>> user
>> > >>>> * defined segment length (seg_len in
>> odp_pool_param_t) will be
>> > >>>> rounded up into
>> > >>>> * this value.
>> > >>>> + *
>> > >>>> + * @return The minimum packet seg_len supported by
>> this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1598)
>> > >>>> +int odp_config_packet_seg_len_min(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum packet segment length
>> > >>>> @@ -104,28 +113,30 @@ extern "C" {
>> > >>>> * This defines the maximum packet segment buffer
>> length in bytes. The
>> > >>>> user
>> > >>>> * defined segment length (seg_len in
>> odp_pool_param_t) must not be
>> > >>>> larger than
>> > >>>> * this.
>> > >>>> + *
>> > >>>> + * @return The maximum packet seg_len supported by
>> this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_PACKET_SEG_LEN_MAX (64*1024)
>> > >>>> +int odp_config_packet_seg_len_max(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * Maximum packet buffer length
>> > >>>> *
>> > >>>> * This defines the maximum number of bytes that can
>> be stored into a
>> > >>>> packet
>> > >>>> - * (maximum return value of odp_packet_buf_len()).
>> Attempts to allocate
>> > >>>> + * (maximum return value of
>> odp_packet_buf_len(void)). Attempts to
>> > >>>> allocate
>> > >>>> * (including default head- and tailrooms) or extend
>> packets to sizes
>> > >>>> larger
>> > >>>> * than this limit will fail.
>> > >>>> *
>> > >>>> - * @internal In linux-generic implementation:
>> > >>>> - * - The value MUST be an integral number of segments
>> > >>>> - * - The value SHOULD be large enough to
>> accommodate jumbo packets (9K)
>> > >>>> + * @return The maximum packet buffer length
>> supported by this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_PACKET_BUF_LEN_MAX
>> (ODP_CONFIG_PACKET_SEG_LEN_MIN*6)
>> > >>>> +int odp_config_packet_buf_len_max(void);
>> > >>>>
>> > >>>> /** Maximum number of shared memory blocks.
>> > >>>> *
>> > >>>> * This the the number of separate SHM areas that
>> can be reserved
>> > >>>> concurrently
>> > >>>> + *
>> > >>>> + * @return The maximum number of shm areas
>> supported by this platform
>> > >>>> */
>> > >>>> -#define ODP_CONFIG_SHM_BLOCKS (ODP_CONFIG_POOLS + 48)
>> > >>>> +int odp_config_shm_blocks(void);
>> > >>>>
>> > >>>> /**
>> > >>>> * @}
>> > >>>> diff --git
>> a/platform/linux-generic/include/odp/config.h
>> > >>>> b/platform/linux-generic/include/odp/config.h
>> > >>>> index 6fecd38..016397e 100644
>> > >>>> --- a/platform/linux-generic/include/odp/config.h
>> > >>>> +++ b/platform/linux-generic/include/odp/config.h
>> > >>>> @@ -17,6 +17,162 @@
>> > >>>> extern "C" {
>> > >>>> #endif
>> > >>>>
>> > >>>> +/**
>> > >>>> + * Maximum number of threads
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_MAX_THREADS 128
>> > >>>> +static inline int odp_config_max_threads(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_MAX_THREADS;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Maximum number of pools
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_POOLS 16
>> > >>>> +static inline int odp_config_pools(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_POOLS;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Maximum number of queues
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_QUEUES 1024
>> > >>>> +static inline int odp_config_queues(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_QUEUES;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Number of scheduling priorities
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_SCHED_PRIOS 8
>> > >>>> +static inline int odp_config_sched_prios(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_SCHED_PRIOS;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Maximum number of packet IO resources
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_PKTIO_ENTRIES 64
>> > >>>> +static inline int odp_config_pktio_entries(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_PKTIO_ENTRIES;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Minimum buffer alignment
>> > >>>> + *
>> > >>>> + * This defines the minimum supported buffer
>> alignment. Requests for
>> > >>>> values
>> > >>>> + * below this will be rounded up to this value.
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_BUFFER_ALIGN_MIN 16
>> > >>>> +static inline int odp_config_buffer_align_min(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_BUFFER_ALIGN_MIN;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Maximum buffer alignment
>> > >>>> + *
>> > >>>> + * This defines the maximum supported buffer
>> alignment. Requests for
>> > >>>> values
>> > >>>> + * above this will fail.
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_BUFFER_ALIGN_MAX (4*1024)
>> > >>>> +static inline int odp_config_buffer_align_max(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_BUFFER_ALIGN_MAX;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Default packet headroom
>> > >>>> + *
>> > >>>> + * This defines the minimum number of headroom
>> bytes that newly
>> > >>>> created packets
>> > >>>> + * have by default. The default apply to both ODP
>> packet input and user
>> > >>>> + * allocated packets. Implementations may reserve
>> a larger than
>> > >>>> minimum headroom
>> > >>>> + * size e.g. due to HW or a protocol specific
>> alignment requirement.
>> > >>>> + *
>> > >>>> + * @internal In linux-generic implementation:
>> > >>>> + * The default value (66) allows a 1500-byte
>> packet to be received
>> > >>>> into a single
>> > >>>> + * segment with Ethernet offset alignment and room
>> for some header
>> > >>>> expansion.
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_PACKET_HEADROOM 66
>> > >>>> +static inline int odp_config_packet_headroom(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_PACKET_HEADROOM;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Default packet tailroom
>> > >>>> + *
>> > >>>> + * This defines the minimum number of tailroom
>> bytes that newly
>> > >>>> created packets
>> > >>>> + * have by default. The default apply to both ODP
>> packet input and user
>> > >>>> + * allocated packets. Implementations are free to
>> add to this as
>> > >>>> desired
>> > >>>> + * without restriction. Note that most
>> implementations will
>> > >>>> automatically
>> > >>>> + * consider any unused portion of the last segment
>> of a packet as
>> > >>>> tailroom
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_PACKET_TAILROOM 0
>> > >>>> +static inline int odp_config_packet_tailroom(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_PACKET_TAILROOM;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Minimum packet segment length
>> > >>>> + *
>> > >>>> + * This defines the minimum packet segment buffer
>> length in bytes. The
>> > >>>> user
>> > >>>> + * defined segment length (seg_len in
>> odp_pool_param_t) will be
>> > >>>> rounded up into
>> > >>>> + * this value.
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_PACKET_SEG_LEN_MIN 1598
>> > >>>> +static inline int odp_config_packet_seg_len_min(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_PACKET_SEG_LEN_MIN;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Maximum packet segment length
>> > >>>> + *
>> > >>>> + * This defines the maximum packet segment buffer
>> length in bytes. The
>> > >>>> user
>> > >>>> + * defined segment length (seg_len in
>> odp_pool_param_t) must not be
>> > >>>> larger than
>> > >>>> + * this.
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_PACKET_SEG_LEN_MAX (64*1024)
>> > >>>> +static inline int odp_config_packet_seg_len_max(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_PACKET_SEG_LEN_MAX;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/**
>> > >>>> + * Maximum packet buffer length
>> > >>>> + *
>> > >>>> + * This defines the maximum number of bytes that
>> can be stored into a
>> > >>>> packet
>> > >>>> + * (maximum return value of
>> odp_packet_buf_len(void)). Attempts to
>> > >>>> allocate
>> > >>>> + * (including default head- and tailrooms) or
>> extend packets to sizes
>> > >>>> larger
>> > >>>> + * than this limit will fail.
>> > >>>> + *
>> > >>>> + * @internal In linux-generic implementation:
>> > >>>> + * - The value MUST be an integral number of segments
>> > >>>> + * - The value SHOULD be large enough to
>> accommodate jumbo packets (9K)
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_PACKET_BUF_LEN_MAX
>> (ODP_CONFIG_PACKET_SEG_LEN_MIN*6)
>> > >>>> +static inline int odp_config_packet_buf_len_max(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_PACKET_BUF_LEN_MAX;
>> > >>>> +}
>> > >>>> +
>> > >>>> +/** Maximum number of shared memory blocks.
>> > >>>> + *
>> > >>>> + * This the the number of separate SHM areas that
>> can be reserved
>> > >>>> concurrently
>> > >>>> + */
>> > >>>> +#define ODP_CONFIG_SHM_BLOCKS (ODP_CONFIG_POOLS + 48)
>> > >>>> +static inline int odp_config_shm_blocks(void)
>> > >>>> +{
>> > >>>> + return ODP_CONFIG_SHM_BLOCKS;
>> > >>>> +}
>> > >>>> +
>> > >>>> #include <odp/api/config.h>
>> > >>>>
>> > >>>> #ifdef __cplusplus
>> > >>>> --
>> > >>>> 2.1.4
>> > >>>>
>> > >>>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> lng-odp mailing
>> listlng-odp@lists.linaro.orghttps://
>> lists.linaro.org/mailman/listinfo/lng-odp
>> <http://lists.linaro.org/mailman/listinfo/lng-odp>
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> lng-odp mailing list
>> > >>> lng-odp@lists.linaro.org
>> <mailto:lng-odp@lists.linaro.org>
>> > >>>https://lists.linaro.org/mailman/listinfo/lng-odp
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >
>> > > _______________________________________________
>> > > lng-odp mailing list
>> > > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org
>> >
>> > >https://lists.linaro.org/mailman/listinfo/lng-odp
>> > >
>> > >
>> >
>> >
>> > --
>> > Mike Holmes
>> > Technical Manager - Linaro Networking Group
>> > Linaro.org <http://www.linaro.org/> *│ *Open source
>> software for ARM SoCs
>>
>>
>>
>>
>>
>> -- Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org <http://www.linaro.org/>***│ *Open source software for
>> ARM SoCs
>>
>>
>>
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
