From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id C3B8A1B53 for ; Thu, 23 Mar 2017 19:51:09 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP; 23 Mar 2017 11:51:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,211,1486454400"; d="scan'208";a="947547391" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 23 Mar 2017 11:51:08 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 23 Mar 2017 11:51:08 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.101]) by FMSMSX155.amr.corp.intel.com ([169.254.5.24]) with mapi id 14.03.0319.002; Thu, 23 Mar 2017 11:51:07 -0700 From: "Eads, Gage" To: Jerin Jacob , "dev@dpdk.org" CC: "thomas.monjalon@6wind.com" , "Richardson, Bruce" , "Van Haaren, Harry" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "santosh.shukla@caviumnetworks.com" Thread-Topic: [dpdk-dev] [PATCH 19/39] event/octeontx: add support worker dequeue function Thread-Index: AQHSlEPb8f/5MyIYdkCIcNMa0R2Y/aGi3xCg Date: Thu, 23 Mar 2017 18:51:07 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E01E90810@FMSMSX108.amr.corp.intel.com> References: <1488562101-6658-1-git-send-email-jerin.jacob@caviumnetworks.com> <1488562101-6658-20-git-send-email-jerin.jacob@caviumnetworks.com> In-Reply-To: <1488562101-6658-20-git-send-email-jerin.jacob@caviumnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 19/39] event/octeontx: add support worker dequeue function 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: Thu, 23 Mar 2017 18:51:10 -0000 Hi Jerin, > +force_inline uint16_t __hot > +ssows_deq_timeout(void *port, struct rte_event *ev, uint64_t > +timeout_ticks) { > + struct ssows *ws =3D port; > + uint64_t iter; > + uint16_t ret =3D 1; > + > + ssows_swtag_wait(ws); > + if (ws->swtag_req) { > + ws->swtag_req =3D 0; > + } else { > + ret =3D ssows_get_work(ws, ev); > + for (iter =3D 1; iter < timeout_ticks && (ret =3D=3D 0); iter++) > + ret =3D ssows_get_work(ws, ev); > + } > + return ret; > +} If I understand this correctly, each ssows_get_work() call will wait up to = N ns, where N is the dequeue_timeout_ns value supplied to ssovf_mbox_getwor= k_tmo_set() in ssovf_configure(). So in ssows_deq_timeout, the wait time is (worst case) timeout_ticks * (N *= (ns to tick conversion factor)) ticks, which depends on the user-supplied = N at eventdev configuration time. Perhaps in ssovf_configure, if the RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT fl= ag is used, the getwork timeout should be set to 1 tick? Thanks, Gage