From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 72A61A0096 for ; Thu, 11 Apr 2019 09:32:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A32A45F19; Thu, 11 Apr 2019 09:32:32 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 615575F0F for ; Thu, 11 Apr 2019 09:32:31 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2019 00:32:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,336,1549958400"; d="scan'208";a="139325930" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.110.206]) by fmsmga008.fm.intel.com with ESMTP; 11 Apr 2019 00:32:28 -0700 Date: Thu, 11 Apr 2019 15:27:07 +0800 From: Ye Xiaolong To: David Marchand Cc: Karlsson Magnus , dev , Ferruh Yigit , Qi Zhang , Topel Bjorn Message-ID: <20190411072707.GA2482@intel.com> References: <20190409151902.14675-1-xiaolong.ye@intel.com> <20190410105327.110410-1-xiaolong.ye@intel.com> <20190411022456.GA114383@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH] net/af_xdp: submit valid count to Tx queue 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190411072707.Q5MgII2nV0UpyY9uYcC_LtZi-dkEUvIZxHMuaZlWMEA@z> On 04/11, David Marchand wrote: >Hello Xiaolong, > >On Thu, Apr 11, 2019 at 4:30 AM Ye Xiaolong wrote: > >> On 04/10, David Marchand wrote: >> >If we reserve N slots, but only submit n slots, we end up with an >> incorrect >> >opinion of the number of available slots later. >> >Either xsk_ring_prod__submit should also update cached_prod (but I am not >> >sure it was the intent of this api), or we must ensure that both reserve >> >and submit are consistent. >> >> I think you are right, current design does have the flaw, I haven't >> thought of >> it before :( So in order to make sure both reserve and submit are >> consistent, what >> about we check the valid count of mbuf at the beginning, then reserve the >> valid >> count slots? >> >> >Ok, I can see other places to inspect in the driver: reserve_fill_queue() >for the same issue, and eth_af_xdp_rx() for a similar issue but with >xsk_ring_cons__peek()/xsk_ring_cons__release() ? >Validating the needed slots count before reserving/peeking in the prod/cons >rings seems the most simple fix. Ok, then I'll handle them in a following patch. Thanks, Xiaolong > > >-- >David Marchand