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 DB049A00E6 for ; Wed, 12 Jun 2019 15:26:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C1A291D009; Wed, 12 Jun 2019 15:26:41 +0200 (CEST) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by dpdk.org (Postfix) with ESMTP id EC54C1C00E for ; Wed, 12 Jun 2019 15:26:39 +0200 (CEST) Received: by mail-pl1-f174.google.com with SMTP id bi6so6242018plb.12 for ; Wed, 12 Jun 2019 06:26:39 -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=t5wH8MXFms3wIARVihytOS7E++lYmfiH+Slsa+LlLxU=; b=k2sr3tGZo90ppHo9X+3w1jrmWm3wGpTqlt92hUXw9ncVCRk2Jd/B+PpeE/6UdI/wN1 83xNjUPDf0TRgYgYDitKpvEpkpIRM4ih406cTiMN3gE+XjNFl0PIjRZ/SpGHykQCDuvb nrLAdyXmyX5qnueAFNUICW1oa6VeHP2EGQr8VxHr/bc3UqySIvVrk/nHFAWekCJbZ7bn gGYgie5fIxp+NPHMBIxSlHjO6Vll5CNLjekKofJDfuuXnuh7oyE6VYcoXgMyMg1z7xoO kO6IPnp2oRKZDpfWrEYk5FRJ4mpErQ5c23ABCZwhRoyeXlJiZ7r0b11vuTwM7vkETdOE 0rQg== 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=t5wH8MXFms3wIARVihytOS7E++lYmfiH+Slsa+LlLxU=; b=cBREgkOVFeXK5Athjb1xwtYZQh1NPkF5iQrm8aPy73nCm8LktVjlyiA/ZXpZJ7PYwl c4WhNBjHevWb2iqywiq5oqi20eDt6A8IbsLE247fVoCq571+rpT8fEFxiGwf+kQ9rZKb lRvrVisy1kzEJKW0WnAXUjTzh2iBpfwW/W4FyINQXyx4Pn0TtuXAd6rNbHmHpA48NN+b fD4XHAZ//DD4ztd/5MQlvaKSj/8KZq7bYgBqyb0P4EsxjSDXqMLunT5lz0PHqk1gK2j2 l/RzZRoTBhSgVYLKy5AnRlZqx+LRRbqaQ6XRYYhSW1SKr8UYm0eZparJLCLrL4Ok7C/4 ReQw== X-Gm-Message-State: APjAAAVCz1vm+s4i/lpk6IIqJ3uFOkOOltxuOCVI2xbNCsAMGBY4172v 4buJsjPawyp7uG5HiwXUMAyC9w== X-Google-Smtp-Source: APXvYqz7YFXrpfMrWA/PIZBrIF7ZYlwjNxqXhKHWZc4MymaATohYYDcFgPcUIQI8GfpHEXfGwSn6uA== X-Received: by 2002:a17:902:a412:: with SMTP id p18mr13695413plq.105.1560345998954; Wed, 12 Jun 2019 06:26:38 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id v5sm17883486pfm.22.2019.06.12.06.26.38 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 12 Jun 2019 06:26:38 -0700 (PDT) Date: Wed, 12 Jun 2019 06:26:37 -0700 From: Stephen Hemminger To: Matan Azrad Cc: "dev@dpdk.org" Message-ID: <20190612062637.57e9ab6e@hermes.lan> In-Reply-To: References: <20190604125409.078adf75@hermes.lan> <20190611072627.7694128c@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 Wed, 12 Jun 2019 05:15:47 +0000 Matan Azrad wrote: > From: Stephen Hemminger > > > 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. > > Ok, I think I got you. > You want to blacklist the PCI device which its netvsc net-device is detected as routed. Do you? > > If so, > > I don't think that probing the pci device hurts the connectivity, only the configuration should hurt it. > > It means that the application configures the device and hurt it. > Doesn't it an application issue? > > Matan Actually probing does hurt, it corrupts the MLX driver. In theory, the driver supports bifurcated but in practice it is greedy and grabs all flows.