From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 86BA5A00E6 for ; Tue, 11 Jun 2019 16:26:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 649E01C3EA; Tue, 11 Jun 2019 16:26:32 +0200 (CEST) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by dpdk.org (Postfix) with ESMTP id 5F61E1C3E9 for ; Tue, 11 Jun 2019 16:26:31 +0200 (CEST) Received: by mail-pl1-f178.google.com with SMTP id cl9so5187199plb.10 for ; Tue, 11 Jun 2019 07:26:31 -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=VtdLKDLd0YRF/Ld6wG2tjqzQBpauld8pOCWK2U/SVpM=; b=lktyyLRDvO6+fnXfuujKCAL4OQSJSkto6SG1VGiw7PJKctZhUzizwiifFgzNfiWc0A ZH+7EAhS/R/Ux6n31TFIZ9Hp5c1KT62Ni5+1jU6SZ3Nvvm99fbUK8kBCaF/iesihfq9j 540wsGAmNdgVvEJoD2esI7mq8QrsEjdw/zyg56rT8GvqVrAjm+LNe6qFJaeARM267tjD gyb0yEl+kFy8/MgMhUsgT8nL6WI69P9cxtuQwutBrKrdtya8JvxswdkHUOvV4IFtwEQX 2XH+u4Y1i+uuAymxLrRsE+zVruSBy2uNOMwprD5be0JX9wH9tW19sQbdwgxXTpxnkQu1 SXEg== 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=VtdLKDLd0YRF/Ld6wG2tjqzQBpauld8pOCWK2U/SVpM=; b=GXB5QGh6aI5EGYsp3MZRDCDbtAcm67UVplyHxXX+rWZfKgCmtskgzChfl9+adpq9+1 qqSx/i7YMbgitC6FxQouG0tcYI1dmmhbl2n3ZRxUsHUYG47xPcu26p8EBqr5LOZIMEa9 Rj9vCQVTgtR+E2dDeytGh+sgYiGfDkKOejRxtMhXKtBe3YhXYQTc7sRbqSgecQuxvL8w I3VSxGeskOETPLMGLgaX1Rd1LUB7abeC8sM5ky9QubdlPG1h1z72w7ZeeYanu2nYJE2I 0mdZYpVdP8GSFXS7PacII9N2Bw0acw0PLO+vADNvaSH65PJQyB8jTypZyBtzFi9pyG1z fmOQ== X-Gm-Message-State: APjAAAVh/F4JHnhvfgkTH/XgLiU8uZrUg5+J7imBU0LMryaRqLlcYZQJ 85y8AtpTfmIHE08+OJPd78+VzcWWA+A= X-Google-Smtp-Source: APXvYqwpj4WDzHE3RLXqr7RbgG1l3Wtu4NjEKcc7+QK8gd0J0dp1H2ptT6I2vSYKFYUmgj/uLWnpTw== X-Received: by 2002:a17:902:b093:: with SMTP id p19mr40779657plr.174.1560263190429; Tue, 11 Jun 2019 07:26:30 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 3sm13812687pfp.114.2019.06.11.07.26.30 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 11 Jun 2019 07:26:30 -0700 (PDT) Date: Tue, 11 Jun 2019 07:26:27 -0700 From: Stephen Hemminger To: Matan Azrad Cc: "dev@dpdk.org" Message-ID: <20190611072627.7694128c@hermes.lan> In-Reply-To: References: <20190604125409.078adf75@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] RFC - vdev_netvsc automatic blacklisting 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 11 Jun 2019 06:21:21 +0000 Matan Azrad wrote: > Hi Stephen > > From: Stephen Hemminger > > When using DPDK on Azure it is common to have one non-DPDK interface. > > If that non-DPDK interface is present vdev_netvsc correctly skip it. > > But if the non-DPDK has accelerated networking the Mellanox driver will still > > get associated with DPDK (and break connectivity). > > > > The current process is to tell users to do whitelist or blacklist the PCI > > device(s) not used for DPDK. But vdev_netvsc already is doing a lot of looking > > at devices and VF devices. > > > > Could vdev_netvsc just do this automatically by setting devargs for the VF to > > blacklist? > > > There is way to blacklist a device by setting it a rout\IP\IPv6, from the VDEV_NETVSC doc: > "Not specifying either iface or mac makes this driver attach itself to all unrouted NetVSC interfaces found on the system. Specifying the device makes this driver attach itself to the device regardless the device routes." > > So, we are expecting that used VFs will be with a rout and DPDK VFs will not be with a rout. > > Doesn't it enough? > > > Matan I am talking about if eth0 has a route, it gets skipped but the associated MLX SR-IOV device does not. When the MLX device is then configured for DPDK, it breaks it for use by kernel; and therefore connectivity with the VM is lost.