[dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event queue config

[Pavan Nikhilesh Bhagavatula]

On Mon, Oct 23, 2017 at 02:45:32PM +0000, Van Haaren, Harry wrote:
> > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula at caviumnetworks.com]
> > Sent: Monday, October 23, 2017 9:42 AM
> > To: Van Haaren, Harry <harry.van.haaren at intel.com>;
> > jerin.jacob at caviumnetworks.com
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event
> > queue config
> >
> > On Mon, Oct 23, 2017 at 08:04:26AM +0000, Van Haaren, Harry wrote:
> > > > From: Pavan Nikhilesh Bhagavatula
> > [mailto:pbhagavatula at caviumnetworks.com]
> > > > Sent: Friday, October 20, 2017 8:09 PM
> > > > To: Van Haaren, Harry <harry.van.haaren at intel.com>
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event
> > > > queue config
> > > >
> > > > On Fri, Oct 20, 2017 at 04:38:57PM +0000, Van Haaren, Harry wrote:
> > >
> > > <big snip>
> > >
> > > > > Sure, I see two sane-ish options:
> > > > >
> > > > > 1) Return an error code from get_attr(), which actually means "ALL
> > TYPES".
> > > > Feels a bit weird, because an error value is really a valid return.
> > > > >
> > > > > 2) Return UINT_MAX (aka, -1) as the scheduling value. Applications
> > that
> > > > use/care about the scheduling type must check, others can ignore it.
> > > > >
> > > > > I'm not sure which of these is the better/less-bad solution. Opinions?
> > -H
> > > > >
> > > >
> > > > I think 1st option would be good, we could use ENOTUNIQ to represent
> > that
> > > > the
> > > > queue type is "ALL TYPE".
> > > >
> > > > Thoughts?
> > >
> > >
> > > OK with me!
> > >
> > Hey Harry/Jerin,
> >
> > Sadly ENOTUNIQ is not supported on freebsd so, would returning EOPNOTSUPP
> > make
> > sense as it is closest error message that has similar meaning.
> > I found ENOATTR in freebsd but that's not supported on linux.
>
>
> EOVERFLOW seems to be supported on both, and suggests that the ALL_TYPES return would "overflow", aka is too big, aka, too many types to return?
>
> Documenting the return is IMO more important that exactly what the value is - given there's no logical errno to use, lets use this and document it clearly so when somebody looks at the docs, they'll gain the correct undersanding?
>

Agreed will spin out a v2.
Thanks for the inputs Harry.

Pavan.

> -H
>