On Tue, Apr 4, 2017 at 4:23 PM, Brian Brooks <[email protected]> wrote: > 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?
I just include a reference to the patch (patchworks URL) in the cover letter. That way reviewers know that to apply this they need to first apply some other pending patch. > >> > >> >> > >> >> > Maxim. >> >> > >> >> >> /** Enqueue mode >> >> >> * >> >> >> * Default value for both queue types is ODP_QUEUE_OP_MT. >> >> >> Application >> >> >> >> >> >
