Hi,
Yes. The above use-case makes sense.
Also we need to document explicit limitation that these variables should be
created before starting the worker threads and that dynamic creation of
variables should be avoided.
Regards,
Bala
On 30 July 2015 at 13:29, Alexandru Badicioiu <
alexandru.badici...@linaro.org> wrote:
> Bala,
> I agree that functions to subtract from a counter or reset it to 0 or
> other value might be required for the completeness.
> I don't see these functions as APIs (since the implementation is the same
> for all HW) but only as an application helper and only in case the
> application uses threads as workers. Implementation defined counters is
> something that we may address in the future.
>
> These helpers can be used the following way:
> Each application defines its own counters, for example in case of
> odp_ipsec one counter can be number of packets/bytes per SA. Based on
> command line switches (e.g. -d packets:sa -d bytes:sa) the main application
> thread builds a global list of counter creation requests before creating
> worker threads.
> When each worker thread starts, it walks the list, creates each requested
> counter and attaches the counter handle to the object it refers to, e.g:
> typedef struct sa_db_entry_s {
> struct sa_db_entry_s *next; /**< Next entry on list */
> ......
> odph_counter_t packets; /**< Counter for SA packets */
> }
> sa_db_entry->packets = odph_counter_create_local(ODPH_COUNTER_SIZE_32BIT);
>
> The assumption here (for simplicity) is that each counter creation call
> returns the same handle in each thread - maybe this should change into
> something like :
> cnt = odph_counter_create_local(ODPH_COUNTER_SIZE_32BIT);
> odph_counter_attach(cnt, sa_db_entry->packets_cnt_list);
> where "packets" member of sa_db_entry changes into an array of
> odph_counter_t .
>
> Each time an SA has processed a packet, the processing thread increments
> (or adds too) the counter:
> odph_counter_add(entry->cipher_sa->packets, 1);
> odph_counter_add(entry->auth_sa->packets, 1);
>
> The main thread has the job to display the global counter value and what
> it does is :
> foreach_sa_db_entry(display_sa_counters, &arg);
>
> static int
> display_sa_counters(sa_db_entry_t *sa_db_entry, void *arg)
> {
> odp_counter_val_t val;
> int len;
> counters_arg_t *_arg = (counters_arg_t *)arg;
> if (sa_db_entry->packets != ODPH_COUNTER_INVALID)
> val = odph_counter_read_global(_arg->thread_tbl, _arg->num,
> sa_db_entry->packets);
> ......
> }
>
> Hope this helps,
> Alex
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 30 July 2015 at 07:20, Bala Manoharan <bala.manoha...@linaro.org>
> wrote:
>
>> Hi,
>>
>> Maybe we need additional API for initialising the counter to reset it to
>> zero and also a need for decrementing the counter?
>>
>> IMO, we need to properly document the use-case of these counter API
>> functions since these counters are thread-specific what will the different
>> between using these APIs and just defining a new thread specific variable
>> in ODP?
>>
>> Regards,
>> Bala
>>
>>
>> On 29 July 2015 at 02:47, Bill Fischofer <bill.fischo...@linaro.org>
>> wrote:
>>
>>> Since counters are likely to be found on performance paths, I'm
>>> wondering if it would make more sense to separate 32 and 64 bit counters
>>> (or just have all counters be 64 bit by default) rather than trying to do
>>> unions that presumably then require discriminator functions to access.
>>>
>>> On Tue, Jul 28, 2015 at 7:54 AM, Alexandru Badicioiu <
>>> alexandru.badici...@linaro.org> wrote:
>>>
>>>> Hi,
>>>> I would like to get your opinions about the opportunity to introduce
>>>> helper functions to enable applications to define and retrieve various
>>>> events or application defined objects related counters, e.g - IPSec SA
>>>> requests/processed packets, IPSec policy match, IPSec policy check
>>>> failures, packets received/sent etc.
>>>>
>>>> Here is a proposal for applications using threads as workers:
>>>>
>>>> typedef enum odph_counter_size {
>>>> ODPH_COUNTER_SIZE_32BIT,
>>>> ODPH_COUNTER_SIZE_64BIT,
>>>> } odph_counter_size_t;
>>>>
>>>> typedef union odp_counter_val {
>>>> uint32_t __u32;
>>>> uint64_t __u64;
>>>> } odp_counter_val_t;
>>>>
>>>> typedef int32_t odph_counter_t;
>>>>
>>>> #define ODPH_COUNTER_INVALID (-1)
>>>>
>>>> /* Create a local (per thread) counter */
>>>> odph_counter_t
>>>> odph_counter_create_local(odph_counter_size_t size);
>>>>
>>>> /* Get counter size */
>>>> odph_counter_size_t
>>>> odph_counter_size(odph_counter_t counter);
>>>>
>>>> /* Add a value to a local counter */
>>>> void
>>>> odph_counter_add(odph_counter_t counter, unsigned int val);
>>>>
>>>> /* Return local counter value */
>>>> odp_counter_val_t
>>>> odph_counter_read_local(odph_counter_t counter);
>>>>
>>>> /* Return global counter value by summing
>>>> all local values */
>>>> odp_counter_val_t
>>>> odph_counter_read_global(odph_linux_pthread_t *thread_tbl, int num,
>>>> odph_counter_t counter);
>>>>
>>>> I know there's an ongoing work to introduce an abstract type for a
>>>> worker, as such these functions would not be usable in a process
>>>> environment.
>>>>
>>>> Thanks,
>>>> Alex
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
