From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) by dpdk.org (Postfix) with ESMTP id CED68330C for ; Thu, 30 Nov 2017 16:10:05 +0100 (CET) Received: by mail-wr0-f173.google.com with SMTP id o2so6925345wro.5 for ; Thu, 30 Nov 2017 07:10:05 -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=IedPH1O7tbqPYdMq9dlqMuoI7IR172Q5LVl4rZEgZUs=; b=JWubbsa7lbRWsPx/5mj5Rvf8g4Cb9kMu+hS6j0lJpgP8MJ2eI/G8RWe5KvCXgSgaqC 6uZumWaRCjf8V6UM2MvWPrXw3x0f8kJ6PIHekogx5yjmT4PHjrVjsfo5FR+wH9SbiEmO g4GoniNhMagAJUuRtxorOtg2mnqBpPGchgKZOq5AwrfgNmWuB3tbNFwO5BY4EOe+rhGr /UR6oUUdvUysUYoBODdebQj0WoDjk8Qtv8JxoNsIxMjOjQU0nIzeTM7E2zI9R+c3iL8o q+w5f5mPMXEcA/atFowTgvGac+XPbUdjOFIv9HnDEYO+nnEeYLgT9jku5ISQm33j82LZ 6ioA== 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=IedPH1O7tbqPYdMq9dlqMuoI7IR172Q5LVl4rZEgZUs=; b=LIrWudY5tW5AwSW2aClo9KTifVOX4HAiBOk4dJlhDr8j42pSb7a6tC+WcDi3BiLPfA h/nvb4vsrNKOSyHWphy6GKp7YFvFghQkBAySolTLOl/quRZt11bJyrF/OX4Wwhkmq8iu km4qRYs1aGvGlFEtYRd9YRBOVUM64k0WxwdsC7KuMnaXVXSemtShYVFLXlZU9/F+hZ2V H2JPWgTXbgTwOifiybYmI1sfFOyAHOUyBg8yStfqJPtSG7T4PAz611g0wqZm1wS2ONFx kk0YWfjn06fazfx5UrAOtVxIDiMUI2J76p9iuPjbqgx6u+DZ4alEkpemeTGTFpdmnGEy JwIg== X-Gm-Message-State: AJaThX6LqLkvFe2FXLGbomuXeIM1170B2CQxr70SK4ZtrPzznTSj8R0x +5/J/vxrjSPAzaI2Q2xFyKPmZg== X-Google-Smtp-Source: AGs4zMbK06oxQ2MVSThnkcaKC4Vil4v0DRDu9+9jKss7nDmu/ULfgLZHIggvyY0TP7yTvilypaU7Eg== X-Received: by 10.223.170.193 with SMTP id i1mr2172094wrc.218.1512054605412; Thu, 30 Nov 2017 07:10:05 -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 b78sm5602909wmi.18.2017.11.30.07.10.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 Nov 2017 07:10:04 -0800 (PST) Date: Thu, 30 Nov 2017 16:09:49 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Matan Azrad Cc: Neil Horman , Thomas Monjalon , Jingjing Wu , "dev@dpdk.org" Message-ID: <20171130150949.tguod6p6s3amxvyq@bidouze.vm.6wind.com> References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <1511870281-15282-3-git-send-email-matan@mellanox.com> <20171130123611.GA20914@hmswarspite.think-freely.org> <20171130132443.4htutb5gpktcshgh@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 2/5] ethdev: add 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: Thu, 30 Nov 2017 15:10:05 -0000 On Thu, Nov 30, 2017 at 02:30:20PM +0000, Matan Azrad wrote: > Hi all > > > -----Original Message----- > > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com] > > Sent: Thursday, November 30, 2017 3:25 PM > > To: Neil Horman > > Cc: Matan Azrad ; Thomas Monjalon > > ; Jingjing Wu ; > > dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership > > > > Hello Matan, Neil, > > > > I like the port ownership concept. I think it is needed to clarify some > > operations and should be useful to several subsystems. > > > > This patch could certainly be sub-divided however, and your current 1/5 > > should probably come after this one. > > Can you suggest how to divide it? > Adding first the API to add / remove owners, then in a second patch set / get / unset. (by the way, remove / delete is pretty confusing, I'd suggest renaming those.) You can also separate the introduction of the new owner-wise iterator. Ultimately, you are the author, it's your job to help us review your work. > 1/5 could be actually outside of this series, it is just better behavior to use the right function to do release port :) > > > > > Some comments inline. > > > > On Thu, Nov 30, 2017 at 07:36:11AM -0500, Neil Horman wrote: > > > On Tue, Nov 28, 2017 at 11:57:58AM +0000, Matan Azrad wrote: > > > > The ownership of a port is implicit in DPDK. > > > > Making it explicit is better from the next reasons: > > > > 1. It may be convenient for multi-process applications to know which > > > > process is in charge of a port. > > > > 2. A library could work on top of a port. > > > > 3. A port can work on top of another port. > > > > > > > > Also in the fail-safe case, an issue has been met in testpmd. > > > > We need to check that the user is not trying to use a port which is > > > > already managed by fail-safe. > > > > > > > > Add ownership mechanism to DPDK Ethernet devices to avoid multiple > > > > management of a device by different DPDK entities. > > > > > > > > A port owner is built from owner id(number) and owner name(string) > > > > while the owner id must be unique to distinguish between two > > > > identical entity instances and the owner name can be any name. > > > > The name helps to logically recognize the owner by different DPDK > > > > entities and allows easy debug. > > > > Each DPDK entity can allocate an owner unique identifier and can use > > > > it and its preferred name to owns valid ethdev ports. > > > > Each DPDK entity can get any port owner status to decide if it can > > > > manage the port or not. > > > > > > > > The current ethdev internal port management is not affected by this > > > > feature. > > > > > > > > The internal port management is not affected, but the external interface is, > > however. In order to respect port ownership, applications are forced to > > modify their port iterator, as shown by your testpmd patch. > > > > I think it would be better to modify the current RTE_ETH_FOREACH_DEV to > > call RTE_FOREACH_DEV_OWNED_BY, and introduce a default owner that > > would represent the application itself (probably with the ID 0 and an owner > > string ""). Only with specific additional configuration should this default > > subset of ethdev be divided. > > > > This would make this evolution seamless for applications, at no cost to the > > complexity of the design. > > As you can see in patch code and in testpmd example I added option to iterate > over all valid ownerless ports which should be more relevant by owner_id = 0. > So maybe the RTE_ETH_FOREACH_DEV should be changed to run this by the new iterator. That is precisely what I am suggesting. Ideally, you should not have to change anything in testpmd, beside some bug fixing regarding port iteration to avoid those with a specific owner. RTE_ETH_FOREACH_DEV must stay valid, and should iterate over ownerless ports (read: port owned by the default owner). > By this way current applications don't need to build their owners but the ABI will be broken. > ABI is broken anyway as you will add the owner to rte_eth_dev_data. > Actually, I think the old iterator RTE_ETH_FOREACH_DEV should be unexposed or just removed, I don't think so. Using RTE_ETH_FOREACH_DEV should allow keeping the current behavior of iterating over ownerless ports. Applications that do not care for this API should not have to change anything to their code. > also the DEFFERED state should be removed, Of course. > I don't really see any usage to iterate over all valid ports by DPDK entities different from ethdev itself. > I just don't want to break it now. > [snip] -- Gaëtan Rivet 6WIND