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 0C2CFA034E; Thu, 7 Nov 2019 15:44:23 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CBBEA1BF05; Thu, 7 Nov 2019 15:44:22 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id F3C4A137D for ; Thu, 7 Nov 2019 15:44:20 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 74A4A70D9; Thu, 7 Nov 2019 09:44:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 07 Nov 2019 09:44: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=tMDVAkGZA4DqURyzgoRQPaLmSWdEHBKfV21TbH0Vd+4=; b=gOi8EKEWI795 i8SpAH8qUWiYdyl18I00gfVjuWFnKlG5w2mtij5bsPXrGWbKMPaTKgQxf91XeKa5 Z5WCdJIehdglLIIJyn8o6qR153hzoEwb/KD50SO45Rc0XdsH3wgAeUNYeWq4pW4i Y7Yq4zNweU3tMqiAUEPpK8/+egcORuk= 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=tMDVAkGZA4DqURyzgoRQPaLmSWdEHBKfV21TbH0Vd +4=; b=RdMyB0wS19xHmgWXNjY4dhjL2l4HkLQiL/IGoG3CkfXG6pw9Rkyw7aViz s5dydPBiPMGZOjDP6PoUJgMtj9ko2jrW42/+rAkWps1j8o7fhZlE3P3m68vd6nMa 9L7w42nWu2fE4KDPCdYwIlC6qXvXP0bIoaf/EOmZirdw2SwvVCkaxZJcdX4pGIlu oc0pRrN+iK/1mwa35SQ8HMv+NNQTrYImTmuDps5SSLKAB1fy9z/JX+jEL/DuvV3t rFq+yU3cA+STE6Cx4+jr8RYZwiqa8ZqNMcFxzB+3Lb04QitQZ8OUCcIr7ecD6Soq 2Jy3APUBQRx/ARbtQjADUOLCqUfSw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduledgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehnvghtuggvvhgtohhnfhdrihhnfhhonecukfhppeejjedrudefgedrvddt fedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlh honhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 D836480060; Thu, 7 Nov 2019 09:44:15 -0500 (EST) From: Thomas Monjalon To: dev@dpdk.org Cc: "Ananyev, Konstantin" , Shahaf Shuler , Ilya Maximets , 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, rasland@mellanox.com Date: Thu, 07 Nov 2019 15:44:14 +0100 Message-ID: <12486120.BHqsEW5yeX@xps> In-Reply-To: <4481782.P5sk1fEGuH@xps> References: <4165509.5enYigmRGf@xps> <2601191342CEEE43887BDE71AB97725801A8C7E88C@IRSMSX104.ger.corp.intel.com> <4481782.P5sk1fEGuH@xps> 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" Bad news for the DPDK API below: 03/11/2019 23:09, Thomas Monjalon: > 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) It seems this confusion and limitation is not scary enough to convince of the right approach. Most probably this figure was not well understood: VF1 ------ VF1 rep /--------\ | switch | uplink rep ------ uplink ------ wire VF2 ------ VF2 rep \--------/ (PF) Please understand that a packet going from the VF rep to the VF, is Tx from the representor point of view, while it is Rx from the VF point of view. It should explain why VF and rep are different. One more explanation: doing Rx/Tx from the VF rep is the way, for a vSwitch, to manage the forwarding in CPU, before offloading it in the HW switch with flow rules. After reading how the representor is implemented in Intel PMDs, I understand there is no intent to do some vSwitch offload with SR-IOV. The Mellanox PMD is capable of such full offload, that's why the representor port must be a real DPDK port, not a ghost. > > > > > > > > > > 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. For information, a Mellanox paper of a netdevconf talk in 2016, which is giving more information about the ideas behind the switchdev model: https://netdevconf.info/1.2/papers/efraim-gerlitz-sriov-ovs-final.pdf > > 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. During the Technical Board yesterday, it was decided to go with Intel understanding of what is a representor, i.e. a ghost of the VF. It was asked to implement the representor operations on the representor port with a special flag to make explicit a non-VF operation. I really tried to implement this reversed logic. One blocker is to check the port ID flag in every functions, including the inline Rx/Tx. So I came to the conclusion that the reverse logic is really ugly and it has no short-term benefit compared to the mix we have currently. After long hours thinking in the night, I prefer focusing on the release. It means we will continue to mix VF and representor operations with the same port ID. For the record, I believe it is very bad.