From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 42B491B204 for ; Thu, 11 Oct 2018 01:38:44 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id r63-v6so7150702wma.4 for ; Wed, 10 Oct 2018 16:38:44 -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=E0wACwMn7FfNGcQc3lsFU05kTTeRigz4X6LvXYJ2EoE=; b=ECoBxmzc4MgnoeZHIBuYyc36EijDKL3tReL6VTioC1Je4w7j0kv9HNzZEsdtmXhRVP Oim6vqsF2T7hZm2bYmFL6Oo4v4AOdhhFdPhHwA0nS4QlW/DQ/A+E4O4R0lhldGtAaRpT xfWl4mnZ5sM2Kqidanzj5dxLDOQTJwE9aYR9w5CE90y4PcL2twn6nVE/d4g24HqsKkUa YX5jl6cNaLyJ1Hrw08RKUeGWorR+q2rNOjpxL+K5M7DnZZcpKdj2qeBKZtmVUbvZ9aI+ ZfWQolnopiCDygmyat/QeRdB4pkBmiqtH9Xbz+qpR+Xuw1mJqmdlDmtzllQUyOhuCXCu +G4Q== X-Gm-Message-State: ABuFfogpVtk1SojjAXDZS0LPOigIfT/Ychp9PWPSCcI8/11n8TtS+egy lkOog10HBBZeSJsysYEFTuhJGq4wHrvx/QzFNSvEJA== X-Google-Smtp-Source: ACcGV63SyNcFn80Ry4CBKW44p9Wyj8pHR1pWe41xWbb9kH5TwY2ZD+CRbarMOW7jZBnCtNtn5daG2Y5i6anQRA2KA9w= X-Received: by 2002:a1c:234c:: with SMTP id j73-v6mr2360826wmj.68.1539214723800; Wed, 10 Oct 2018 16:38:43 -0700 (PDT) MIME-Version: 1.0 References: <20180628224513.18391-1-dg@adax.com> <20180629015508.26599-1-dg@adax.com> <20180629015508.26599-3-dg@adax.com> <611163de-bef7-488b-a77b-0e1ff190f1fb@intel.com> <0596f426-0fc5-a222-ea68-4407669f9b22@intel.com> In-Reply-To: From: Dan Gora Date: Wed, 10 Oct 2018 20:38:07 -0300 Message-ID: To: Ferruh Yigit Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 02/10] kni: separate releasing netdev from freeing KNI interface 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: Wed, 10 Oct 2018 23:38:44 -0000 I'll have a look at this.. Maybe it will work, I'll have to try it and test it to see if there are any gotchas that are not obvious. d On Wed, Oct 10, 2018 at 7:51 PM Ferruh Yigit wrote: > >> Very simply, what about prevent kni_net_release() send callback to userspace? > > > > No, because how is the DPDK application going to know when the user > > does 'ip link set down dev '? It's important for the DPDK > > application to know when the KNI interface is marked down. > > I mean kni_net_release() called because of unregister_netdev(), > > it is possible to set a flag in kni_dev_remove(), before unregister_netdev(), > and in kni_net_release() don't call kni_net_process_request() if flag is set. > > Looks like it can work and only a few lines of code, what do you think? > > > > >> This is already not working and removing it resolves the issues you mentioned. > > > > Huh? How is it not working? Of course it works. > > The kni_net_release() called because of unregister_netdev() is not working, as > you explained in userspace the thread handles request already terminated, even > if not in kernel side response not received and timed off because of lock... > > > > >> Sample application calls rte_eth_dev_stop() after release itself, so behavior > >> will be same. > > > > Huh? > > in kni sample app, in kni_free_kni() rte_eth_dev_stop() is called after > rte_kni_release(). > So if you prevent kni_net_release() called because of unregister_netdev() to > send callback it won't be problem because of existing rte_eth_dev_stop() >