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 2CE98A00BE; Wed, 30 Oct 2019 16:49:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E03151C027; Wed, 30 Oct 2019 16:49:58 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 2CFA51BFF5 for ; Wed, 30 Oct 2019 16:49:57 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 4FCA06FB3; Wed, 30 Oct 2019 11:49:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 11:49:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Mfjy0cxvH/cpBgoqNdXNqOXrCBjbp8pZfkblV5hhu4k=; b=ReNfuTYCHACL MZVW7nU+r51b0LchKQ96M2KuH2dyGFqU8AuCYIv1nqlIYh9ny6djADJjJkDqZFtX 54kszkhOQq8Dso5M7m+Dy22cnk5pZhVcFliNTsLPdejH6I46UV4RW1bnZSfYNebd A+W7MCMILhBNm7xWuFj3SM5WxJCvaho= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Mfjy0cxvH/cpBgoqNdXNqOXrCBjbp8pZfkblV5hhu 4k=; b=V5fXoG8FZ/gJ3uDNfVmHbYxKdkRz73YgnUxsJFmhrNveLxkd1FENYsq28 /a3PiYczlxlf5og2zTZA/2uVIGj7O6dkb4Og+3yQgxW2y8UXDL3Xd5RthFLhVGmO XH71qavGgtizBRM+bPPxsNL6F/q0wPwRIPXosb8RCDXR6QdlO8M1akFslaWflDNu gj7H+ypqx+7isP5OxKMcshePqiNdGQNRhi5VzVz+2f7VANoEytOjdLDLB0wmAeEl Kqt5c+XLMy4xPqZdPeLsm3RzIdg5pa5DmLtyXyXikIF9nzKqiuUmINk0N7y8k5Sg u7Onpv2QHGRTbv09m/h/KM0Pux94A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtfedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A5DFE8006C; Wed, 30 Oct 2019 11:49:53 -0400 (EDT) From: Thomas Monjalon To: Ilya Maximets Cc: dev@dpdk.org, Shahaf Shuler , Jerin Jacob , Andrew Rybchenko , Ferruh Yigit , Stephen Hemminger , Roni Bar Yanai , Rony Efraim , declan.doherty@intel.com, bernard.iremonger@intel.com, ferruh.yigit@intel.com, arybchenko@solarflare.com Date: Wed, 30 Oct 2019 16:49:51 +0100 Message-ID: <5190422.ormd5srm06@xps> In-Reply-To: <0fd4b3fc-ec27-484d-8ed6-370fa7905eb6@ovn.org> References: <4165509.5enYigmRGf@xps> <20191029185051.32203-1-thomas@monjalon.net> <0fd4b3fc-ec27-484d-8ed6-370fa7905eb6@ovn.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 30/10/2019 16:07, Ilya Maximets: > On 29.10.2019 19:50, Thomas Monjalon wrote: > > In a virtual environment, the network controller may have to configure > > some SR-IOV VF parameters 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, > > and PMD-specific APIs were used. > > So, what is wrong with setting VF mac via the representor port as > it done now? From our previous discussion, I thought that we concluded > that is enough to have current API, i.e. just call set_default_mac() > for a representor port and this will lead to setting mac for VF. > This is how it's implemented in Linux kernel and this is how it's > implemented in current DPDK drivers that supports setting mac for > the representor. I don't know what is done in the Linux kernel. In DPDK, setting the MAC of the representor is really setting the MAC of the representor. Is it crazy? > The only use case for this new API is to be able to control mac of > the representor itself, which doesn't make much sense. At least there > are only hypothetical use cases. And once again, Linux kernel doesn't > support this behavior. I think it is sane to be able to set different MAC addresses for the representor and the VF. > > This new generic API will avoid vendors fragmentation. > > I don't see the fragmentation. Right now you can set VF mac from DPDK > by calling set_default_mac() for representor. This API exists for all > vendors. Not implemented for Intel, but new API is not implemented too. No, the current situation is the following: - for mlx5, VF MAC can be configured with iproute2 or netlink - for ixgbe, rte_pmd_ixgbe_set_vf_mac_addr() - for i40e, rte_pmd_i40e_set_vf_mac_addr() - for bnxt, rte_pmd_bnxt_set_vf_mac_addr() > The this is that this new API will produce conceptual fragmentation > between DPDK and the Linux kernel, because to do the same thing you'll > have to use different ways. I mean, to change mac of VF in kernel you > need to set mac to the representor, but in DPDK changing setting mac to > representor will lead to changing the mac of the representor itself, > not the VF. This will be really confusing for users. I am not responsible of the choices in Linux. But I agree it would be interesting to check the reason of such decision. Rony, please could you explain?