From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dmarchan@redhat.com> Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by dpdk.org (Postfix) with ESMTP id 528305B3C for <dev@dpdk.org>; Thu, 11 Apr 2019 09:20:20 +0200 (CEST) Received: by mail-vs1-f53.google.com with SMTP id t23so466881vso.10 for <dev@dpdk.org>; Thu, 11 Apr 2019 00:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ogdUZfJ7FvF0IK0NyQcVa+sr3p6VyGvq+QtApKNiCoI=; b=Aah8E9wfoxM2PPYlm1BEKLGhtT26SnD/hTz6YG+HTyVVGDAH9DB9HAi03QwDvEZaVK IFDQJ38bC4KN28WiNqfyyss0S7iOL3SAgw7POfnlEHFvnvLJtjJAGtt9nDEL1HcRz0Re mNUyt15j5cUJCEDgDvpTxwSJvMjS/by+/e+G0Q4xaodCQZ/cQH6PiGD0tbhMMD4UaEhX dHzZKZVfPRDk2258dKHPs7NunFQDAJamfRvBkfZoC1Qoodou5h6CLci33WIBCRoD2+pi CLkuAxfizda6eMwLtSf2d+g4wizilSh+RD5V4dfLqYam/IAmna50L/lkgenv1XL9uHcM A+YQ== X-Gm-Message-State: APjAAAWKwcypg69Fy8flDPt6GQFr5rizVsaCPeIew3QldHUJNfX7DkTB ZAE2glWysyKgynMHNpetU0L36FuXZf4zkMU6BgFxcA== X-Google-Smtp-Source: APXvYqzILqDR8+j3/00FHRWdE8R48yMYh8EBCGikW8uRV9T3BVeOn+CXZibLT2XfayH5/zFc2psnocXQSc4fFfIeYts= X-Received: by 2002:a05:6102:199:: with SMTP id r25mr25010615vsq.166.1554967219660; Thu, 11 Apr 2019 00:20:19 -0700 (PDT) MIME-Version: 1.0 References: <20190409151902.14675-1-xiaolong.ye@intel.com> <20190410105327.110410-1-xiaolong.ye@intel.com> <CAJFAV8zGRW9gXa+ewwBsrzCLyHckpgBDiPyjMfEZ2P2_=EJM_Q@mail.gmail.com> <20190411022456.GA114383@intel.com> In-Reply-To: <20190411022456.GA114383@intel.com> From: David Marchand <david.marchand@redhat.com> Date: Thu, 11 Apr 2019 09:20:08 +0200 Message-ID: <CAJFAV8y=fHuFWrbuH7fHB3kAHxiQMexmPSKvN+4v1nKVv3QAcg@mail.gmail.com> To: Ye Xiaolong <xiaolong.ye@intel.com> Cc: Karlsson Magnus <magnus.karlsson@intel.com>, dev <dev@dpdk.org>, Ferruh Yigit <ferruh.yigit@intel.com>, Qi Zhang <qi.z.zhang@intel.com>, Topel Bjorn <bjorn.topel@intel.com> Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 11 Apr 2019 07:20:20 -0000 Hello Xiaolong, On Thu, Apr 11, 2019 at 4:30 AM Ye Xiaolong <xiaolong.ye@intel.com> 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. -- David Marchand From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 97CD4A0096 for <public@inbox.dpdk.org>; Thu, 11 Apr 2019 09:20:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5B81B5B3E; Thu, 11 Apr 2019 09:20:21 +0200 (CEST) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by dpdk.org (Postfix) with ESMTP id 528305B3C for <dev@dpdk.org>; Thu, 11 Apr 2019 09:20:20 +0200 (CEST) Received: by mail-vs1-f53.google.com with SMTP id t23so466881vso.10 for <dev@dpdk.org>; Thu, 11 Apr 2019 00:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ogdUZfJ7FvF0IK0NyQcVa+sr3p6VyGvq+QtApKNiCoI=; b=Aah8E9wfoxM2PPYlm1BEKLGhtT26SnD/hTz6YG+HTyVVGDAH9DB9HAi03QwDvEZaVK IFDQJ38bC4KN28WiNqfyyss0S7iOL3SAgw7POfnlEHFvnvLJtjJAGtt9nDEL1HcRz0Re mNUyt15j5cUJCEDgDvpTxwSJvMjS/by+/e+G0Q4xaodCQZ/cQH6PiGD0tbhMMD4UaEhX dHzZKZVfPRDk2258dKHPs7NunFQDAJamfRvBkfZoC1Qoodou5h6CLci33WIBCRoD2+pi CLkuAxfizda6eMwLtSf2d+g4wizilSh+RD5V4dfLqYam/IAmna50L/lkgenv1XL9uHcM A+YQ== X-Gm-Message-State: APjAAAWKwcypg69Fy8flDPt6GQFr5rizVsaCPeIew3QldHUJNfX7DkTB ZAE2glWysyKgynMHNpetU0L36FuXZf4zkMU6BgFxcA== X-Google-Smtp-Source: APXvYqzILqDR8+j3/00FHRWdE8R48yMYh8EBCGikW8uRV9T3BVeOn+CXZibLT2XfayH5/zFc2psnocXQSc4fFfIeYts= X-Received: by 2002:a05:6102:199:: with SMTP id r25mr25010615vsq.166.1554967219660; Thu, 11 Apr 2019 00:20:19 -0700 (PDT) MIME-Version: 1.0 References: <20190409151902.14675-1-xiaolong.ye@intel.com> <20190410105327.110410-1-xiaolong.ye@intel.com> <CAJFAV8zGRW9gXa+ewwBsrzCLyHckpgBDiPyjMfEZ2P2_=EJM_Q@mail.gmail.com> <20190411022456.GA114383@intel.com> In-Reply-To: <20190411022456.GA114383@intel.com> From: David Marchand <david.marchand@redhat.com> Date: Thu, 11 Apr 2019 09:20:08 +0200 Message-ID: <CAJFAV8y=fHuFWrbuH7fHB3kAHxiQMexmPSKvN+4v1nKVv3QAcg@mail.gmail.com> To: Ye Xiaolong <xiaolong.ye@intel.com> Cc: Karlsson Magnus <magnus.karlsson@intel.com>, dev <dev@dpdk.org>, Ferruh Yigit <ferruh.yigit@intel.com>, Qi Zhang <qi.z.zhang@intel.com>, Topel Bjorn <bjorn.topel@intel.com> Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190411072008.iugRgzwJ47GwThU3CbFXxZj6SrelbYC4DwEiQeo6pXo@z> Hello Xiaolong, On Thu, Apr 11, 2019 at 4:30 AM Ye Xiaolong <xiaolong.ye@intel.com> 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. -- David Marchand