From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 94570231E for ; Mon, 23 Oct 2017 16:45:36 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2017 07:45:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,423,1503385200"; d="scan'208";a="163824427" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga005.jf.intel.com with ESMTP; 23 Oct 2017 07:45:34 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.180]) by IRSMSX107.ger.corp.intel.com ([169.254.10.239]) with mapi id 14.03.0319.002; Mon, 23 Oct 2017 15:45:33 +0100 From: "Van Haaren, Harry" To: Pavan Nikhilesh Bhagavatula , "jerin.jacob@caviumnetworks.com" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event queue config Thread-Index: AQHTQ1xG14824kEOX0adMmqVvtGmd6Lse9HggAAJnYCAAHYPIIAAGu0AgAQNx6D///nPgIAAddGw Date: Mon, 23 Oct 2017 14:45:32 +0000 Message-ID: References: <1507814147-8223-1-git-send-email-pbhagavatula@caviumnetworks.com> <20171020103032.GA7404@PBHAGAVATULA-LT> <20171020190927.GA18722@PBHAGAVATULA-LT> <20171023084138.GA27709@PBHAGAVATULA-LT> In-Reply-To: <20171023084138.GA27709@PBHAGAVATULA-LT> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODJiYjM1N2QtY2I2ZC00YzEwLWE0MGYtNmUxMmQyMThkZDYzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ikg5bjRLcHBnRWhRamVPWU1lXC9sazFUOFFmbDNWTko0blppVGVMN0xoaTc0PSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event queue config X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 14:45:37 -0000 > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com= ] > Sent: Monday, October 23, 2017 9:42 AM > To: Van Haaren, Harry ; > jerin.jacob@caviumnetworks.com > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event > queue config >=20 > On Mon, Oct 23, 2017 at 08:04:26AM +0000, Van Haaren, Harry wrote: > > > From: Pavan Nikhilesh Bhagavatula > [mailto:pbhagavatula@caviumnetworks.com] > > > Sent: Friday, October 20, 2017 8:09 PM > > > To: Van Haaren, Harry > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in eve= nt > > > queue config > > > > > > On Fri, Oct 20, 2017 at 04:38:57PM +0000, Van Haaren, Harry wrote: > > > > > > > > > > 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. Opinio= ns? > -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, >=20 > 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 re= turn 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 cle= arly so when somebody looks at the docs, they'll gain the correct undersand= ing? -H