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 A3939A0352; Sun, 3 Nov 2019 23:09:25 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 04CD41BE94; Sun, 3 Nov 2019 23:09:24 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id D01501BE93 for ; Sun, 3 Nov 2019 23:09:21 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id DCCFF4A6E; Sun, 3 Nov 2019 17:09:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 03 Nov 2019 17:09:19 -0500 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=8bCmbO3zKLQBnAhAFVONWCiXBVLdcWZWfaTyZjL5YDg=; b=ioUNl0jTDRSA 2cA9JfmUfihz9kXd4verf/Tirrl/sQ7K6WXlHyO1dQqJOIN7d05OCSuz0RZCk9DG HVA5NbGqvmolEYLXQL299F54/UrE33em1Vb+Ysz7i/MHhlez13MUFYqBrzS+IKyr jdenIoI30o3dqV/9Cg7SLgzwqc6iAow= 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=8bCmbO3zKLQBnAhAFVONWCiXBVLdcWZWfaTyZjL5Y Dg=; b=VnrN6/Oe7QffD/tllq3Owoho3rNUkWEKrOSHpWe9RhPjS9vA3ttNJrYc/ ShuEbhjK/tqrhR8JDrVnreoqxCR/AUDQF2fx9rDuW05RghqFHyt85RlfEVTgW86I kH9EmSlhlNevyWLdJaiQAnL5gN0NK6L1aQJWDa3SCXSgpwU7GsyUYXUPSx0xH+cA nFAnbCGznBN23bvO5G32LOI9tYteE8UqRohAw7XonDnWuWkFXatceXcUPxHga9I9 pUG0SltO7gadB+VNsQ2WXHyRLIpLHS176qRPtxde1/gE/PAaxYicqkqxOqyQ4Kuj AsLr1qTJk5MLcL8RCAuUa/7Rygbmg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduuddgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepleefrddvfedrvdegkedrvddtkeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (208.248.23.93.rev.sfr.net [93.23.248.208]) by mail.messagingengine.com (Postfix) with ESMTPA id E819480062; Sun, 3 Nov 2019 17:09:14 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: Shahaf Shuler , Ilya Maximets , "dev@dpdk.org" , Jerin Jacob , Andrew Rybchenko , "Yigit, Ferruh" , Stephen Hemminger , Roni Bar Yanai , Rony Efraim , "Doherty, Declan" , "Iremonger, Bernard" , "ajit.khaparde@broadcom.com" , david.marchand@redhat.com Date: Sun, 03 Nov 2019 23:09:12 +0100 Message-ID: <4481782.P5sk1fEGuH@xps> In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C7E88C@IRSMSX104.ger.corp.intel.com> References: <4165509.5enYigmRGf@xps> <2601191342CEEE43887BDE71AB97725801A8C7E88C@IRSMSX104.ger.corp.intel.com> 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" 03/11/2019 16:27, Ananyev, Konstantin: > > > > > If we consider what Intel did, i.e. configure VF in place of > > > > representor for some operations, there are two drawbacks: > > > > - confusing that some ops apply to representor, others apply to VF > > > > - some ops are not possible on representor (because targetted to VF) > > > > > > > > I still feel that the addition of one single bit in the port ID is an > > > > elegant solution to target either the VF or its representor. > > > > > > Since we already have a confusion about what is configured when operations > > > are performed on a representor port we have 2 options: > > > > I don't agree we have. I don't think there is any design note or API doc that says the ethdev configuration on representor should be applied > > on VF (please share if I missed it). > > The fact that there are some drivers that implemented it doesn't mean it is correct. > > Well, it means that at least authors and reviewers of these patches, > plus probably next-net maintainers believe that it is correct. > At least they did - when patch was applied. > If that is not clearly stated in the doc - it might be just the gap in the documentation, Gap in the documentation? We should state that the config should be applied to the port specified with port_id and no other one? Funny > that needs to be fixed, not a mandate to break existing behavior. So because you managed to have a wrong patch applied in your PMD, you want to make it the generic API in ethdev? What a process! Hey guys, if you want to change an API behaviour in a way others don't, you just have to implement what you want in your PMD silently, then you will be able to change the API to comply with your behaviour. Wonderful. If we allow such practice, DPDK is dead.