On 04/04 15:20:06, Bill Fischofer wrote:
> On Tue, Apr 4, 2017 at 3:11 PM, Brian Brooks <[email protected]> wrote:
> > On 04/04 14:22:25, Bill Fischofer wrote:
> >> On Tue, Apr 4, 2017 at 1:53 PM, Maxim Uvarov <[email protected]> 
> >> wrote:
> >> > On 04/04/17 21:47, Brian Brooks wrote:
> >> >> Signed-off-by: Brian Brooks <[email protected]>
> >> >> Signed-off-by: Honnappa Nagarahalli <[email protected]>
> >> >> ---
> >> >>  include/odp/api/spec/queue.h | 5 +++++
> >> >>  1 file changed, 5 insertions(+)
> >> >>
> >> >> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
> >> >> index 7972feac..1cec4773 100644
> >> >> --- a/include/odp/api/spec/queue.h
> >> >> +++ b/include/odp/api/spec/queue.h
> >> >> @@ -124,6 +124,11 @@ typedef struct odp_queue_param_t {
> >> >>         * the queue type. */
> >> >>       odp_queue_type_t type;
> >> >>
> >> >> +     /** Queue size
> >> >> +       *
> >> >> +       * Indicates the max ring size of the ring buffer. */
> >> >> +     uint32_t ring_size;
> >> >> +
> >> >
> >> > As Petri said api should say that has to be min size or requested size.
> >> > I.e. implementation can allocate more then this size.
> >>
> >> This seems to be a repost of v1. As mentioned in the earlier comments:
> >>
> >> 1. This needs to be size, not ring_size, since ring is an
> >> implementation model, not something inherent to the API
> >>
> >> 2. We need a corresponding update to odp_queue_capability() to return
> >> a max_size (or sizes)
> >>
> >> 3. The queue validation test needs to be updated to reflect these changes.
> >>
> >> 4. The user guide will need a documentation update to cover this as well.
> >>
> >> Given that this is orthogonal to the rest of this series, the
> >> suggestion was that it be posted as a separate series so we can
> >> contrast it to Petri's suggested changes covering this area.
> >
> > Please keep an eye out for a patch from Honnappa. Until then, this is just
> > for testing purposes. Whenever a patch for this change lands in api-next
> > I can respin and drop it.
> 
> You can co-req another patch series as part of your patch series. That
> way you don't have to keep posting duplicate or obsolete code.

Is there a formal way to specify the co-req for v3?

> >
> >> >
> >> > Maxim.
> >> >
> >> >>       /** Enqueue mode
> >> >>         *
> >> >>         * Default value for both queue types is ODP_QUEUE_OP_MT. 
> >> >> Application
> >> >>
> >> >

Reply via email to