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 E3BC4A0C4D; Mon, 4 Oct 2021 16:14:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 72C2141377; Mon, 4 Oct 2021 16:14:15 +0200 (CEST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mails.dpdk.org (Postfix) with ESMTP id 33A32412D2 for ; Mon, 4 Oct 2021 16:14:14 +0200 (CEST) Received: by mail-pj1-f54.google.com with SMTP id pi19-20020a17090b1e5300b0019fdd3557d3so65634pjb.5 for ; Mon, 04 Oct 2021 07:14:14 -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=rBpRvo9wMYG+5pvUg5wYHqkkoS+qwc5Oh75Qg4Q/dtQ=; b=h7+3J27CW9seh0Gud1BDgwLDq6H8+E19xbGkjhIWowKvz4jsYuzXxDlmx2VLaENN3H QHnulh66mhmH+gV66Ok7RSfYc2QBhG25lPFF7cfeozImxa3uD4JVC+Foub/iQFptWb3Z EfgBZx5CeSmOxWaD8hZ/1iB2RWRdmIGJ0SJkiXJYFHfDRkUdSkJjjFYoP/Pru4iIg51b LnbxlGwea3YVDX9/1MW/OlJi7LbexO5VyxG8fZyBKyQOSS60CGeuDCUH7J7FpuJyj4gA rviVPTOPaJnQQTjQxBnTuvSRUupxLXJIaJRn1RvKProiJJaKgeW7+B7exMGRXju4kiLg 3JUw== 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=rBpRvo9wMYG+5pvUg5wYHqkkoS+qwc5Oh75Qg4Q/dtQ=; b=pDvSK2Q5zfqu+tepn1+rTjkI/Cn9nSv3gagJzkWuNs7d3HcrurzJX7brRgKFNNQMlt Rm3OxbmHbgdJYtNma0lbggfM+GcMIpA+xOyl8hF9y8aVyMGyEmAc8rTocYcaN9FPl6LV Bg9orpjjn4hJ2VXTlgUhCEVJK+je8rksycEcKUhtEwNwCfPALsTosJzKodiZaLp8NctH Tq1++genp4LJDiPtYC3J8PM2wUo3qSGjDERVCotXLXcU6sTCusLPKDnQdO1R/EZyXxTV iR3D4xJbaocTg8TMRk+IsAZgGolG7w1x5mbTVYtrAuvO5q9egPjirUvdYP2uMlgfjcj7 H9sg== X-Gm-Message-State: AOAM533EBmpkRikMJVXoAdVxGl96Qa2YLMxDSjQx/6jtz5e2mkRpf+z6 1Tpn10No8sPGsj0C0OqeqT5kEOvIHglaszz0n4o= X-Google-Smtp-Source: ABdhPJz5V4cqlElsMm3tSIdmtB7z0CAMn6mWo8zQKIUPDljE38kDWyu0hVIRW4xXqVSaw6aRtnxQrcZKl9WOVztXa4E= X-Received: by 2002:a17:902:a50d:b0:13d:8d71:aa91 with SMTP id s13-20020a170902a50d00b0013d8d71aa91mr23608946plq.24.1633356851829; Mon, 04 Oct 2021 07:14:11 -0700 (PDT) MIME-Version: 1.0 References: <20210924105409.21711-1-eladv6@gmail.com> In-Reply-To: From: Eric Christian Date: Mon, 4 Oct 2021 10:14:00 -0400 Message-ID: To: Ferruh Yigit Cc: Elad Nachman , dev@dpdk.org, Igor Ryzhov , sahithi.singam@oracle.com Content-Type: text/plain; charset="UTF-8" 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" Adding Sahithi. I believe adding the -EAGAIN method puts the responsibility on the application/caller. If we take the change MAC address as an example. Most application code just does this kind of check: ret = ioctl(sockfd, SIOCSIFHWADDR, &ifr); if (ret < 0) { PMD_LOG_ERRNO(ERR, "ioctl(SIOCSIFHWADDR) failed"); return -EINVAL; } So the existing application code will treat the -EAGAIN as a failure and not retry. Unless it is expected that the IOCTL can return -EAGAIN and the application decides to keep retrying? We can try this, but we have temporarily patched out the async changes in our code as it was blocking QA due to https://bugs.dpdk.org/show_bug.cgi?id=816 Eric On Mon, Oct 4, 2021 at 9:05 AM Ferruh Yigit wrote: > 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 = (struct rte_kni_request *)kni->sync_kva; > > + if (cur_req->req_in_progress) { > > + ret = -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 kni > module? > >