On 16 April 2015 at 15:10, Savolainen, Petri (Nokia - FI/Espoo) <
[email protected]> wrote:

> Event is a thing that can be transmitted through queues. Event gives you
> the event type - nothing more. User needs to convert the received event
> according to its event type ...
>
> buf = odp_buffer_from_event(event);
>
> .. to access the information
>
> my_msg = odp_buffer_addr(buf);
>
> Buffer gives you the minimal support for transferring bytes through
> queues. Some events, like timeouts, may have only metadata (not variable
> sized user data).
>
I agree that this is the concept. But it would be useful for easy of reuse
that timeouts could be implemented on top of buffers (any buffer
implementation as defined by the specific platform). Timeouts should still
be a specific event type. The extra timeout data (96 bits) could be stored
in the buffer data (currently it is stored after the buffer header, this is
what creates the portability problem).

Linux-generic is almost doing this as it uses
odp_buffer_alloc/odp_buffer_free to allocate and free timeouts. The buffer
handle is converted to an event handle which is then converted to a timeout
handle (this last conversion converts back the event to a buffer and then
returns the pointer to the  buffer header, the timeout handle is the
pointer to the buffer header).

All of this is just implementation, not API. But it would be useful to be
able to reuse the linux-generic timer implementation on other platforms
which lack suitable timer HW. There is already more than one such platform
and I expect most ODP platforms not to have that kind of HW timer support.

I will rewrite the timeout event/pool implementation in linux-generic and
see where it lands.


> -Petri
>
>
> > -----Original Message-----
> > From: lng-odp [mailto:[email protected]] On Behalf Of ext
> > Zoltan Kiss
> > Sent: Thursday, April 16, 2015 3:58 PM
> > To: Ola Liljedahl; Mike Holmes
> > Cc: lng-odp-forward
> > Subject: Re: [lng-odp] odp timers
> >
> >
> >
> > 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_NpcJ87
> > yfaD8/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
>
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to