From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5D0D5A0C4D; Mon, 4 Oct 2021 16:25:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DBED341340; Mon, 4 Oct 2021 16:25:32 +0200 (CEST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by mails.dpdk.org (Postfix) with ESMTP id 14C34412D2 for ; Mon, 4 Oct 2021 16:25:32 +0200 (CEST) Received: by mail-io1-f42.google.com with SMTP id i62so20476434ioa.6 for ; Mon, 04 Oct 2021 07:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=msZ7eyz1r8jBQAUfdPMgkQtNZs54sQK6EJQv5o7mtTo=; b=W9r1L9oTmiLCx5Upt4zhVp/mT7bgYogrKEr5vCuZ805TFUkjyxYsMl8vh8xBxjJLHP Iut5vVYfSztAkKGNLnoyvP7gC2JjHHRM4FsPavPNKr6ofBYajvxNci0WyjkTdahz7wKr ZQK9JCfvsGFvpkT4VL+5g1odEMabYuQzsvDikUnGQ9zlaMsA9tJIY7FjR0BfO9wMt/2z 5nevnvxPhj5nzsp6reE1BuJEF/pm5FjlPTEv5EMoJ4IO9IUfQiGLDUAbCxt0qUntFJpT xPejFuBZdGPb14PF1WLNVD+tZEP+j3y0+cN05XWraJt+9nvyG6AXGUewuYtMX+h5cjZG pJZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=msZ7eyz1r8jBQAUfdPMgkQtNZs54sQK6EJQv5o7mtTo=; b=ZCauc9jUAQY2YNXBSOacJwdmPIfL7PXID3QNwo1hfw2B9oOisIy8KA/dOrJHxQGwEe 4wDVDLzThPxJXHGVeaVMpl6VYiWR9GQuI1gRxCDFc8o5a8NSaSt4BnTQqcvygUmQNr4L IM2qWEEwm3UjCnICCrF9I+Eernq/NUTG7ouZV93mYdgt7Nplt0ErxHCXANkqHCZqcV4o g4J9+Nh+jmrqvtLivsG/wOpGOEg1Jrg7pOhNewhXllFNW0ZO7L+9w+W8KiN+JbA2xdsC K902sK3J/OIJyWnr7Akgpod1pU9UOLlNWcQPJZ1eHqvCeKnnfub2H1IojGzY48fOj6bH vJnA== X-Gm-Message-State: AOAM533TQ2ZcJlgp39fl3k0tjWfKaHHjKIl+Fv53AytdaD4womdnDOWn xDYga5aQw1SDIFRIFoIEQrkqupF3/lXFabqfvs4= X-Google-Smtp-Source: ABdhPJxlGIeYXtq4f+Po6ue41vYA+pn6gFCqpMFH0E5Ci84U++XvjVsIAecNnV+KQo6TUSFyz7YQJF/6bfaqKmQduIQ= X-Received: by 2002:a05:6638:a2d:: with SMTP id 13mr11032377jao.12.1633357531412; Mon, 04 Oct 2021 07:25:31 -0700 (PDT) MIME-Version: 1.0 References: <20210924105409.21711-1-eladv6@gmail.com> <3ae193df-292c-4907-df4a-88ce3d6735fc@intel.com> In-Reply-To: <3ae193df-292c-4907-df4a-88ce3d6735fc@intel.com> From: Elad Nachman Date: Mon, 4 Oct 2021 17:25:19 +0300 Message-ID: To: Ferruh Yigit Cc: Eric Christian , dev , Igor Ryzhov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v2] kni: Fix request overwritten X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 1. Userspace will get an error 2. Waiting with rtnl locked causes a deadlock; waiting with rtnl unlocked for interface down command causes a crash because of a race condition in the device delete/unregister list in the kernel. FYI, Elad. =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=91=D7=B3, 4 =D7= =91=D7=90=D7=95=D7=A7=D7=B3 2021, 17:13, =D7=9E=D7=90=D7=AA Ferruh Yigit = =E2=80=8F< ferruh.yigit@intel.com>: > On 10/4/2021 2:09 PM, Elad Nachman wrote: > > Hi, > > > > EAGAIN is propogated back to the kernel and to the caller. > > > > So will the user get an error, or it will be handled by the kernel and > retried? > > > We cannot retry from the kni kernel module since we hold the rtnl lock. > > > > Why not? We are already waiting until a command time out, like > 'kni_net_open()' > can retry if 'kni_net_process_request()' returns '-EAGAIN'. And we can > limit the > number of retry for safety. > > > FYI, > > > > Elad > > > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=91=D7=B3, 4= =D7=91=D7=90=D7=95=D7=A7=D7=B3 2021, 16:05, =D7=9E=D7=90=D7=AA Ferruh Yigi= t =E2=80=8F< > > ferruh.yigit@intel.com>: > > > >> On 9/24/2021 11:54 AM, Elad Nachman wrote: > >>> Fix lack of multiple KNI requests handling support by introducing a > >>> request in progress flag which will fail additional requests with > >>> EAGAIN return code if the original request has not been processed > >>> by user-space. > >>> > >>> Bugzilla ID: 809 > >> > >> Hi Eric, > >> > >> Can you please test this patch, if it solves the issue you reported? > >> > >>> > >>> Signed-off-by: Elad Nachman > >>> --- > >>> kernel/linux/kni/kni_net.c | 9 +++++++++ > >>> lib/kni/rte_kni.c | 2 ++ > >>> lib/kni/rte_kni_common.h | 1 + > >>> 3 files changed, 12 insertions(+) > >>> > >> > >> <...> > >> > >>> @@ -123,7 +124,15 @@ kni_net_process_request(struct net_device *dev, > >> struct rte_kni_request *req) > >>> > >>> mutex_lock(&kni->sync_lock); > >>> > >>> + /* Check that existing request has been processed: */ > >>> + cur_req =3D (struct rte_kni_request *)kni->sync_kva; > >>> + if (cur_req->req_in_progress) { > >>> + ret =3D -EAGAIN; > >> > >> Overall logic in the KNI looks good to me, this helps to serialize the > >> requests > >> even for async ones. > >> > >> But can you please clarify how it behaves in the kernel side with > '-EAGAIN' > >> return type? Will linux call the ndo again, or will it just fail. > >> > >> If it just fails should we handle the re-try on '-EAGAIN' within the k= ni > >> module? > >> > >> > >