On 15/04/15 22:45, Ola Liljedahl wrote:
On 15 April 2015 at 18:22, Mike Holmes <[email protected]
<mailto:[email protected]>> wrote:



    On 15 April 2015 at 12:14, Zoltan Kiss <[email protected]
    <mailto:[email protected]>> wrote:

        Btw. is there any documentation which describes the underlying
        concepts behind timeouts (why are they buffer types?) and events?

Timeouts are a primary event type, just like buffers and packets. How
they are implemented is platform specific.
Ok, but what are the expectations towards these buffer types? I mean something like these: - timeout buffers are expected to be able to store 10200 bytes, because that's the size of my favourite cute kitten image - packet buffers should support segmentation (this one at least is defined in packet.h implicitly), but raw buffers shouldn't
- etc.


The linux-generic implementation uses buffers for timeouts, Petri (?)
added odp_timeout_alloc() and odp_timeout_free() when we migrated to the
event-based pool system.
I'm also missing a good documentation written down about why are buffers are events, why is it better? How is it different? What's the rationale? What exactly are "events" in this case? So last night when I had a beer with my friends, what kind of buffer was that? ;) I have some vague ideas about that, but even searching the mailing list archives doesn't help.

 I am not sure the design is now 100% correct as
odp_timer.c imposes a timeout_header onto the timeouts that are actually
buffers. Can we be sure that there is actually space for the three
fields that odp_timeout_hdr_t adds to odp_buffer_hdr_t? And can you
always call odp_buffer_alloc() with a pool of type ODP_TYPE_TIMEOUT?
This seems to be expected by odp_timeout_alloc() and odp_timeout_free()
today.

platform/linux-generic/include/odp_timer_internal.h:
typedef struct {
         /* common buffer header */
         odp_buffer_hdr_t buf_hdr;

         /* Requested expiration time */
         uint64_t expiration;
         /* User ptr inherited from parent timer */
         void *user_ptr;
         /* Parent timer */
         odp_timer_t timer;
} odp_timeout_hdr_t;

For portability reasons (reuse linux-generic timer implementation on
other platforms), it would be better if timeouts were plain buffers with
the extra timeout fields in the buffer data, not in the event header.
Then any buffer implementation could be used for the timeout events. The
timeouts must still have the event type ODP_TYPE_TIMEOUT.


    We have doc [1] which may not be current.
    We do need to address the availability documentation in 2015, it is
    generally hard to find or incomplete.

       [1]
    
https://docs.google.com/document/d/1bfY_J8ecLJPsFTmYftb0NVmGnB9qkEc_NpcJ87yfaD8/edit



        On 15/04/15 11:27, Maxim Uvarov wrote:

            Hello Ola,

            I have some questions about odp timers, can you please
            provide expertise
            for that?

            odp_timeout_alloc() use pool and calls odp_buffer_alloc(pool).

            Is it supposed that timeout buffer carries packet data to be
            send? Is
            there is requirement to allocate that from pool memory which
            can be used
            for packet transition?


            Looks like timer carries only user_ptr and timer structs.

            So that it should be possible to use linux-generic timers
            for other
            platforms like dpdk almost as is.

            Thanks,
            Maxim.


            _______________________________________________
            lng-odp mailing list
            [email protected] <mailto:[email protected]>
            https://lists.linaro.org/mailman/listinfo/lng-odp

        _______________________________________________
        lng-odp mailing list
        [email protected] <mailto:[email protected]>
        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
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to