From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f44.google.com (mail-pl0-f44.google.com [209.85.160.44]) by dpdk.org (Postfix) with ESMTP id 80123D018 for ; Mon, 16 Apr 2018 19:18:36 +0200 (CEST) Received: by mail-pl0-f44.google.com with SMTP id k9-v6so5613470pll.12 for ; Mon, 16 Apr 2018 10:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=fpjOrwc6AduNb3sQtXJAVmBGuN0Ie2scaX1qFs9hrDc=; b=081jl6XByn2GbBQigcuWeM4f4alcj2DrrYnZq3GPuNjYD3ggQfWUJIsfBh3zmrLif6 cjoWUMKTCrKD/PHQNo8KPev63PcYyMNeACFRb5pm34YljQ6MZQVqSP2UJF9Vpkg1Aif7 ZdU6R8YYkvCo9V+h/6001fqy0O8C9PzxM+9bw0gWpvRzMIgZYeUosq7YKB2F3069RuNN 9C1k75RCXHdFdBae4SFiUkf8PNSy7OFkOKhjDYIyPJKIwK0TIPKbbZkm4qJgYAiWuPZM BSwkMz1+PeFSkviEaLT5I4DCsNxNSnNEzlikhZtkHbipWRgPcvj5e0EOU2qWS44HFeK+ zWJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=fpjOrwc6AduNb3sQtXJAVmBGuN0Ie2scaX1qFs9hrDc=; b=gaT5W8zZWufvYIRrmD3LyD6eRaRZ1sD0+gCyXAt8gxup+bmRFQodVhC6j1USO77d+1 DjgsXWUMZezEuy9KziHrAgx5bxCl2i9VE08DcMiAgFuId3vll1Jv0xqjcTIjNz4RQaoS 1v/zSKrFG2z7VlrKGUt8Ro2KZuQCaYsjgAGxk1dd4lkLDu4UwVFKCKkUQixltzjsq2Kl ZFPCZu7meqk6sisgBex37wyRH4U3eXGM5rq2vxHEFw68Kc0mx97XUU3kpyya+hRXfD4I kqr2Jra++q9RCvLvfQuT/ll21S58qUQMEtzCOhZjtUq9uCxImx4RqwDkppnsC8gvt7t6 BlUg== X-Gm-Message-State: ALQs6tArRBOarPNAo9g11xVaX2WbpVY6SEejS6xgmk+wefqhPKEk96en bzp8uZDkFYpbWM5OizOf90sedQ== X-Google-Smtp-Source: AIpwx4+aiaWLxYJuAiXoxCo7g/b1Hi3mtkaITZvdpyr27aDXD4u+ztqarPhu5obS6iZ/tES+n+8uUg== X-Received: by 2002:a17:902:6b87:: with SMTP id p7-v6mr6682625plk.101.1523899115651; Mon, 16 Apr 2018 10:18:35 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id t11sm21823432pgn.94.2018.04.16.10.18.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Apr 2018 10:18:35 -0700 (PDT) Date: Mon, 16 Apr 2018 10:18:30 -0700 From: Stephen Hemminger To: Matan Azrad Cc: Bruce Richardson , "Burakov, Anatoly" , Thomas Monjalon , "dev@dpdk.org" , "pmatilai@redhat.com" , "david.marchand@6wind.com" , "jia.guo@intel.com" , "konstantin.ananyev@intel.com" , "fbl@redhat.com" Message-ID: <20180416101830.0a78c430@xeon-e3> In-Reply-To: References: <2407757.yEAnF6RcS7@xps> <20180413164046.GD37024@bricha3-MOBL.ger.corp.intel.com> <20180416083153.GA50020@bricha3-MOBL.ger.corp.intel.com> <20180416095723.0d7698c7@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] kernel binding of devices + hotplug 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: Mon, 16 Apr 2018 17:18:36 -0000 On Mon, 16 Apr 2018 17:10:09 +0000 Matan Azrad wrote: > Hi Stephen > > From: Stephen Hemminger, Monday, April 16, 2018 7:57 PM > > On Mon, 16 Apr 2018 16:11:12 +0000 > > Matan Azrad wrote: > > > > > > If the device management is only managed in one place, i.e. not in > > > > DPDK, then there is no conflict to manage. > > > > > > I can't agree with this statement, > > > The essence of DPDK is to give a good alternative to managing network > > > devices, DPDK actually takes a lot of management area to manage by > > > itself to do the user life better :) > > > > More is not better! DPDK is poorly integrated into Linux overall system. Doing > > more in DPDK makes this worse not better. > > In this case I think that yes, more is better. > Please explain why do you think that in this case it is worse. DPDK should work with udev, not try and replace functionality that is already done by udev and systemd. Having a parallel and different model makes life harder for users. > > > Buried under this discussion is the fact that the Mellanox bifurcated driver > > behaves completely differently from every other driver. This makes coming > > to a common solution much harder. The bifurcated model has advantages > > and disadvantages, in this case it is a disadvantage since it is not easy to > > manage usage when it is a shared resource. > > Sorry, what is your point? The bifurcated model does not play well with driverctl. It just works differently than other drivers. The bifurcated model works better for simple case of shared device on bare metal; but it is harder for the transparent bonding model used on Azure. The eth device is not really available for direct use in kernel; and there is discussion in netdev about hiding it as well which will break more things here.