From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 80A3DA00BE; Wed, 30 Oct 2019 05:08:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A428D1BEC1; Wed, 30 Oct 2019 05:08:54 +0100 (CET) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 08E131BEB9 for ; Wed, 30 Oct 2019 05:08:52 +0100 (CET) Received: by mail-io1-f67.google.com with SMTP id q1so955233ion.1 for ; Tue, 29 Oct 2019 21:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rAraeLXKTY8rvrSre4n7VJeitDomGwRX7IDDDaq2whw=; b=ItvUCp96S1Pd6TFu4ZUgNbAwVm3Hm8YllxoWQJk2k2d8BBEJs+4X37oY2HtqUQqmOu nLbfC6LbDbCVJI+q7PVwvOLYlG0bZyBB4v2M8q0D2mM0eoVG+8tNdu06b/FRCZnFBmfn gU4WKzlpImhfY+1Gio39qhVB+BlecLBXS4nnBrP2WGJbMrv+9Jfzncgm9iPKP0ENRcXi m9wptQV+DcIiFwlnNdtanJIw7otzzA1Jo/gE2trNbS9BzLS8dDfxP04/rY4QS7uSGxCf msgZq6PkUJP5KZZBarGhfoV07KctLhZ+lG6f/YCdRU1czjnXkQp9aQkvTafJiJegwC01 J/yg== 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=rAraeLXKTY8rvrSre4n7VJeitDomGwRX7IDDDaq2whw=; b=nozgL6PyRubPl1Uw3bWE6r4uhOJvIWn9+SvWNprptf+lWn7E0rMuCCnRJD1bag0jiy 9BakuDs3nG52q1ljerau5Vs6F3fdKnILTZ9mu57ITIR9mRIAdl6+hXIWS3LCNe5EluLD 7he7MJ7KlOvBsScvdhKTDo/KgkroGlQNO4rGjKgrHRsO1L0Nk/JDWN5KBEOTjsJbSiOw CLt/ft/+UTFFDkH+a4HU/ST5WigqKgiqUTIbgVGXFlG7iWJJqDgrGOipIY4NGjQfHB2O r+wS0dlw3PKj9Cu/ptTGBS99PG27CWRKldvB5ytVkHm23GySa+wW6WYyGvEw02qSrFpN K7Eg== X-Gm-Message-State: APjAAAXiS8iViR8Y6kXNobMtP4N6oVI6rMux3Ohk09vFhb8zzs3p71lm 2u75zTmnqY3zOonalpmgVTXmdQ4XNj0LvBvvq28= X-Google-Smtp-Source: APXvYqwVfqFpsAm3QC9B9bn0GwR1xKi8bCRDCDtzdDGOySauQ+8yen1/PgddxMwjIik/ir6ZuvT0fimRJR446S/g86g= X-Received: by 2002:a02:b604:: with SMTP id h4mr26341128jam.112.1572408531914; Tue, 29 Oct 2019 21:08:51 -0700 (PDT) MIME-Version: 1.0 References: <4165509.5enYigmRGf@xps> <20191029185051.32203-1-thomas@monjalon.net> In-Reply-To: <20191029185051.32203-1-thomas@monjalon.net> From: Jerin Jacob Date: Wed, 30 Oct 2019 09:38:36 +0530 Message-ID: To: Thomas Monjalon , Stephen Hemminger , Andrew Rybchenko , Ferruh Yigit Cc: dpdk-dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from host 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, Oct 30, 2019 at 12:21 AM Thomas Monjalon wrote: > > In a virtual environment, the network controller may have to configure > some SR-IOV VF parameters for security reasons. Just to understand, Could you explain more details/examples for security reasons? > > When the PF (host port) is driven by DPDK (OVS-DPDK case), > we face two different cases: > - driver is bifurcated (Mellanox case), > so the VF can be configured via the kernel. > - driver is on top of UIO or VFIO, so DPDK API is required, Not true. Both UIO and VFIO are NOT allowed to create SRIOV VF from the PF device. It is only allowed through igb-uio out of tree driver without iommu support. > and PMD-specific APIs were used. > This new generic API will avoid vendors fragmentation. The API is good. But I have concerns about the vendor implementation of this API. It can support only vendors with bifurcated driver(Mellanox case). or using igb_uio(non iommu case) but not the devices with VFIO(Which is the first-class citizen). All the control plane control stuff to replace Linux with "port representor" logic will be of the mercy of an "out of tree" driver either with igb_uio or http://patches.dpdk.org/patch/58810/ I am _not against_ on DPDK supports port representor or controlling netdev VF traffic, but if we have taken that path then DPDK should have the infrastructure to support for all driver models like VFIO(Addressed in [1]) I would have this question when DPDK starts supporting port representor(but I was not aware that kernel security issue on netdev ports controlled by DPDK in non-bifurcated driver case and concise effort block such scheme by kernel [2]) [1] http://patches.dpdk.org/patch/58810/ [2] https://patchwork.kernel.org/patch/10522381/ > > Some PMD-specific API could migrate to this generic model. > As an example, the default MAC address configuration is demonstrated > for a VF mapped to mlx5 representor port. > > As it breaks the ABI, I propose to merge this API in DPDK 19.11-rc2. > > I am sorry I had not send a patch since proposing a RFC in August. > (I gave priority to the summit and the -rc1 release) > > > Thomas Monjalon (3): > ethdev: identify SR-IOV VF from host > ethdev: set VF MAC address from host > net/mlx5: set VF MAC address from host > > drivers/net/mlx5/mlx5.c | 6 +++ > drivers/net/mlx5/mlx5.h | 1 + > drivers/net/mlx5/mlx5_mac.c | 19 ++++++++ > lib/librte_ethdev/rte_ethdev.c | 55 +++++++++++++++++++++--- > lib/librte_ethdev/rte_ethdev.h | 38 ++++++++++++++++ > lib/librte_ethdev/rte_ethdev_core.h | 1 + > lib/librte_ethdev/rte_ethdev_version.map | 1 + > 7 files changed, 114 insertions(+), 7 deletions(-) > > -- > 2.23.0 >