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 D7E90A00BE; Fri, 1 Nov 2019 12:01:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 431E51BEF0; Fri, 1 Nov 2019 12:01:36 +0100 (CET) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id B97972BF3 for ; Fri, 1 Nov 2019 12:01:34 +0100 (CET) Received: by mail-il1-f195.google.com with SMTP id f201so2696852ilh.6 for ; Fri, 01 Nov 2019 04:01:34 -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=nzNcL8lzVg0GM+0Innu6DTEd1jQQa9VBWEry+JRFSc4=; b=f/HqRREZYVWsOArzytd0S/enhRR3ucZcXXqgKZsW3Pwp8bR0lwlCWK4EVQJOyg8XB5 UxYZPoxg4hwv8e14XorIJeUe9sWENgOrw7pL/UiM2L9NU924ib+yJTORxZsvjsb6UsxV bTeQ+ORnSeONFPsQcKVi0hDBAAlww5ESSuvX6NkTQuDTDok79p6G1pClQ/lZGH1ntZ0s hdlPDj02gHoest2lXhAwoZjFB7gO5MWnpFvnppB2PlsMuaq/UZcaJIHhMXnSN7nDeznb bzduLuGi4xF+AjXagQ3a1d6ymaVkrxsLLiPBM5o561IjN/s8TEaid9w/qoAij+a/xV2R InSQ== 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=nzNcL8lzVg0GM+0Innu6DTEd1jQQa9VBWEry+JRFSc4=; b=HsCCoEZCM8aD0gPqQpapkx1aJw2xkT0hTe4ej/6i5wQ0UQfBzwVQNtGOGLEm5r1/qd 94WHMtianMbd2s4/Q0Tjy+mi/flLKalGXfI7RddSS2vYpoSb9lClJi29lr5UK4b2UCR/ ybMp+PGwxmw/j+8IcOwPxAtPrD5cEB/dGHAfH0DC7SBcHu3JTUrClKzt5JZbRLuxldvS xH+wohxOPnVD/nq1qu+DQSktFpL16deUpegVATIJdVl5Is4YzDw2fBBwI8VW17SRgBC7 XNcpnwa/2RnZEVb72xB4a4Rtaf1WDnq2k0upwjbwWEgu8yB+IY22pPwVZHOqfeZqCd1/ 8pUw== X-Gm-Message-State: APjAAAVJr0gN+TI6MKEOvSE5UyidrNbh8MtsMOm/nzdreaLYksUrJVbY 0EvoKWyZRtqQC1QOwO+1IFVR0dtGulwkUELmTNw= X-Google-Smtp-Source: APXvYqx1k4KiJRsC2/QXwezMJYbZqnqeqVzvg9ah3pDgM5FGRBpb5GbrSXiCySZRh60MQ3zCb7TXX/WvFPkb30vJNbk= X-Received: by 2002:a92:aa48:: with SMTP id j69mr11813529ili.162.1572606093796; Fri, 01 Nov 2019 04:01:33 -0700 (PDT) MIME-Version: 1.0 References: <4165509.5enYigmRGf@xps> <4976847.S65dXbhd2F@xps> <19415242.5f0JWZHRpF@xps> In-Reply-To: <19415242.5f0JWZHRpF@xps> From: Jerin Jacob Date: Fri, 1 Nov 2019 16:31:17 +0530 Message-ID: To: Thomas Monjalon Cc: dpdk-dev , Stephen Hemminger , Andrew Rybchenko , Ferruh Yigit 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 Fri, Nov 1, 2019 at 6:03 AM Thomas Monjalon wrote: > > 30/10/2019 10:15, Jerin Jacob: > > On Wed, Oct 30, 2019 at 2:26 PM Thomas Monjalon wrote: > > > > > > 30/10/2019 05:08, Jerin Jacob: > > > > 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? > > > > > > Examples are setting the MAC address or the promiscuous mode. > > > These settings should be decided by the hypervisor, > > > and not freely set by the VM. > > > > What is hypervisor here, rte_flow based DPDK application over using > > port representor? > > Yes, something like that. An example is OpenStack/OVS. > > > > 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. > > > > > > Not sure I said the contrary. > > > igb_uio and vfio_pf are 2 implementations of UIO and VFIO. > > > > Yes. I am saying without out of tree module it is not possible. > > > > > > > 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). > > > > > > Why not? (see above) > > > The API is agnostic to the kernel driver in use. > > > > My question is how do you enable in DPDK with VFIO if DPDK is giving > > this feature? > > I didn't get your question. > If it is the same question as before, I think you can create the VF > before binding the PF to VFIO. No more. Following patch made to stop that hack. https://patchwork.kernel.org/patch/10522381/ > > > > > 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/ > > > > > > I feel you are using this thread to promote your vfio_pf implementation. > > > > Yes. I am. Because, I need to think, How I can enable this API with VFIO. > > Otherwise, I can not implement this API. > > > > > But this API and the kernel module are orthogonals. > > > Please can we focus on the DPDK API in this thread, > > > and talk about VFIO implementation in the other thread? > > > > Yes. My concerns are we keep adding APIs without thinking about how it > > can be implemented > > in the overall scheme of things. Just API is not enough. > > We keep thinking about all scenarios (maybe in other threads). > And adding an API is a step in the right direction in my opinion. I am not against DPDK adding the API. My concerns are Linux kernel folks don't like the parrel infrastructure we are building with port representor bypassing Linux kernel tools and infrastructure tools. ie, DPDK controlling the Netdev VFS due to security issues. And I agree. The Mellanox case is not an issue as bifurcated driver architecture. But all other vendors will have the issue. (using UIO or VFIO) > >