From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 38F042BF5 for ; Mon, 8 Jan 2018 15:21:57 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id a79so14523165wma.0 for ; Mon, 08 Jan 2018 06:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=w2j4thMp5++TXCN+W4QFKgI1rgyVYOgjs6n87AyFQ3U=; b=sO/kc+OOYP78WTqQwobL49mXK9T36W8Yo1EgWktFn28aCFisjS9GuRX8WsUC6dyzGi +OumKh4SF8n+HHU6jTQmCOtxdb3cpvsFpuXKEW7oUWhnkw3MRLTb3I7ySehnfFv8Xk4E acZGbKZGgvSmQDok6W6yuoVLBoRsNVYAoPOxkE0VN8HOjfwYo89ir/lvhi6bov/RRN7A es2sa0Q6xUHamloPnwG0rla26I5AXXRAs+ihiSztYEWBlO4fXZCaz0eV8M2c3zR9ZhHF AsT9BxJjinXNVrcdftgC9EqXiNRdvS1IELVF8T1gbfeH8uKKGjl/TBxdOHCR5+IqLQpv 4eBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=w2j4thMp5++TXCN+W4QFKgI1rgyVYOgjs6n87AyFQ3U=; b=aU71iYZ2ECuy7stliZOUaUKASDG/yzaG4O5iyYaaiZs+laFfuQpbZey8yJWnrBjSL0 QGAD7uZg82CqtI0CA71zFqOLBJal47e3Zoov4TDM2gCxSD7UJKjzVS9G7IerrCx/ihVV hr/iGqDo8odx+EM4eGA/kskOQ94fpwtRbNqaU4etSSMOmYiPAw0IfQbAC+nQBK4qziwr kDW2eFq5gkDqOdZIhq8Ut9lfcskxlSykDZ1+5XYSo9VhVJFuvFIYGc6OQlqZJF72yY4R QDrpPsl1D+5vu/6pey9J3xTo+BMXz82Zrpw337CXvmSoZn5komNXwcEfcKSTtj5ZUaMo 1pWg== X-Gm-Message-State: AKGB3mLkV44NGynWTuhzmvyfLmMw4ROZUhkYLS9HXcCCQDGSLemIZW/p PEe7L4qNLB6ybErtw+emKR0Ub8NM X-Google-Smtp-Source: ACJfBosCPWsR94mUVm5EIQrAx5imzI7gxdTIzgPVh0EJhpjaZaZzG1+SPhllwiySWakOKWTsmaWi5g== X-Received: by 10.28.137.140 with SMTP id l134mr9453951wmd.29.1515421316736; Mon, 08 Jan 2018 06:21:56 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id y134sm16828354wme.12.2018.01.08.06.21.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Jan 2018 06:21:55 -0800 (PST) Date: Mon, 8 Jan 2018 15:21:43 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Matan Azrad Cc: Thomas Monjalon , Jingjing Wu , "dev@dpdk.org" , Neil Horman , Bruce Richardson , Konstantin Ananyev Message-ID: <20180108142143.nk6c6l64nqnurfhz@bidouze.vm.6wind.com> References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <1515318351-4756-1-git-send-email-matan@mellanox.com> <1515318351-4756-7-git-send-email-matan@mellanox.com> <20180108113946.hcgxvulamjsiepre@bidouze.vm.6wind.com> <20180108133015.an547uygefjz5gj4@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 6/6] app/testpmd: adjust ethdev port ownership 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: , X-List-Received-Date: Mon, 08 Jan 2018 14:21:57 -0000 On Mon, Jan 08, 2018 at 01:55:52PM +0000, Matan Azrad wrote: > Hi Gaetan > > From: Gaëtan Rivet, Monday, January 8, 2018 3:30 PM > > On Mon, Jan 08, 2018 at 12:30:19PM +0000, Matan Azrad wrote: > > > > > > > > > From: Gaëtan Rivet, Monday, January 8, 2018 1:40 PM > > > > Hi Matan, > > > > > > > > On Sun, Jan 07, 2018 at 09:45:51AM +0000, Matan Azrad wrote: > > > > > Testpmd should not use ethdev ports which are managed by other > > > > > DPDK entities. > > > > > > > > > > Set Testpmd ownership to each port which is not used by other > > > > > entity and prevent any usage of ethdev ports which are not owned by > > Testpmd. > > > > > > > > > > > > > This patch should not be necessary. > > > > > > > > Ideally, your API evolution should not impact the default case. As > > > > such, the default iterator RTE_ETH_FOREACH_DEV should still be used in > > testpmd. > > > > > > > Why? We want to adjust testpmd to the port ownership. > > > > > > > This adjustment should be seamless for existing application. > > > > > > RTE_ETH_FOREACH_DEV should call > > RTE_ETH_FOREACH_DEV_OWNED_BY, with > > > > the default owner (meaning that it would thus iterate on the > > > > application-owned set of device). > > > > > > > > > > It will break the API (we already talked about it). > > > There is not any default owner: > > > Any DPDK entity includes applications must to allocate an owner ID and use > > it to own the ports they wants to use. > > > The application can include more than 1 owner depends on the user needs. > > > Each DPDK entity which can synchronize all its port usage can be a valid > > DPDK entity for the ownership mechanism. > > > > > > > That's the point of my remark: you did not include a default owner. > > I think there should be one, and that all ports should pertain to this default > > owner by default when created. > > > > This would not prevent a user or application from adding new owners specific > > to their use and specialize ports if need be. > > > > However, for other applications that do not care for this specialization, they > > should run with the current API and avoid the ports that are configured by > > other third parties. > > > > RTE_ETH_FOREACH_DEV means iterate over all devices and should stay as is in my opinion. > I understand your concern about changes in current application, > But your "default" suggestion will cause to "non-default" applications to reset all the default owners and will complicate them and hurt semantics. Why should an application be able to iterate over all ports? Leave this capability to the EAL (or ethdev layer) alone, while other components should be restricted to their specific set. And if a need for this general iterator appears, solutions could be found very easily. RTE_ETH_FOREACH_DEV currently does not iterate over deferred ports, it iterates over the base set of ports available. Changing this behavior is not necessary, you could introduce your API while keeping it. > > > I'm thinking about applications already written that would be used with fail- > > safe ports: they would use RTE_ETH_FOREACH_DEV, and would thus iterate > > over every ports, including those owned by the fail-safe, unless they start > > following the new API. > > > > They should start, it is really not complicated. The point is not whether developpers downstream would be able to grasp such complexity, but whether a project like DPDK should foster an unstable environment for its currently still limited ecosystem. > What's about application which use count=rte_eth_dev_count and iterate over all ports from 0 to count-1? > We cannot save all the wrong application options. > > > This is unnecessary: adding a default owner for all created ports and > > redefining RTE_ETH_FOREACH_DEV as follow > > > > #define RTE_ETH_FOREACH_DEV(i) > > RTE_ETH_FOREACH_DEV_OWNED_BY(i, RTE_ETH_DEFAULT_OWNER) > > > > Is simple enough and will simplify the work of DPDK users. Moreover, it > > would make fail-safe compatible with all applications using > > RTE_ETH_FOREACH_DEV without additional evolution. It would actually make > > any code using your API supported by those same applications, which I think > > would help its adoption. > > > > Will break API, will hurt semantic of FOREACH , and will complicate ownership care applications as I wrote above. Well, breaking an API is best before such API is integrated anyway. I disagree regarding the added complexity for applications that would use ownership. With your proposal, most applications will only add a single user and register all their ports with this user, then be forced to iterate upon their registered user. You can save all of them the hassle of adding this code, by taking care of the most common case, avoiding redundant code downstream and simplifying possible future update to this default case. So if anything, this would greatly simplify ownership for the vast majority of applications. -- Gaëtan Rivet 6WIND