From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 96DC6108F for ; Wed, 6 Sep 2017 12:17:50 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3579C20CDF; Wed, 6 Sep 2017 06:17:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 06 Sep 2017 06:17:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=VhMH7vF0zfF0/hzB7aqO0vC6Ot6GeXF8d/Ez3K 5mXOM=; b=BqpsOXmQXiQ1WotRBiMiIhkuDsKGR3VeYbQ3d9s/4IPbGVOyGiT0iM CQeG1FHQFlGm+PgDS8yxpZcNY9eLFq0Hyi3QNKVV9PozVVGTYm/fAeQz358/ZBGo iZGqw81BOR30t6V08HbPLg6aZU3jG6SsAdw/gKeWk2xcENUOSILJo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=VhMH7vF0zfF0/hzB7a qO0vC6Ot6GeXF8d/Ez3K5mXOM=; b=YPv3TDEvLk2CDaNAsoztTYjtZ4HiGum1KP Lqb6WyLEiT+BakoCLzb27nERd9CXYyg85jmLd8XH6DK9vEZnZEvAtAgKqUa5OoMd G+J4jc6+7cQs2B5xCB+gKOdN9xLgii9BkUc+h0BoOuIIqzVrdcX0VIL+8fLzODXE JM1Ea1SlV7JFOsfZAIcIWKyD+CTb//hebIqQX90WBl1Qi1MGclQWJaz9ag8cILba OX0t85nnw92RThMhEr0YIVQnFGWsFHU7BK70xUrl6UA06oNOT6kgCtcTH/QgVb79 auv2gsH/jNnHyqGGnMwoboSbG4bek9idkYAsRrXbcTeerRxSqg+A== X-ME-Sender: X-Sasl-enc: YIdL212LTEjtJRcJKaKsjLkGnoO6iIgEu8DFNna2a3KB 1504693068 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DC16D24335; Wed, 6 Sep 2017 06:17:48 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: gaetan.rivet@6wind.com, matan@mellanox.com Date: Wed, 06 Sep 2017 12:17:48 +0200 Message-ID: <1702878.F75W0GzqAz@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [dpdk-dev] new ethdev API proposal for 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: Wed, 06 Sep 2017 10:17:50 -0000 Hi all, A DPDK queue is designed to be polled by only one thread. And the port settings must be managed by only one entity/thread. These assumptions come from lockless design and management logic. - thank you Captain Obvious ;) That's why we can say that an ethdev port is owned by one entity. Note that this discussion can also apply to cryptodev or eventdev. The ownership of a port is implicit in DPDK. I propose to make it explicit for several reasons I explain below. 0/ Explicit is better than implicit 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 (failsafe design). In the failsafe 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 failsafe: http://dpdk.org/ml/archives/dev/2017-September/074253.html Now let's discuss how to implement the port ownership. When failsafe has been introduced, the need of skipping owned ports has been adressed with a new "deferred" state: http://dpdk.org/commit/cb894d99ec http://dpdk.org/commit/5588909af2 It allows to iterate over "free" ports but not to check one port. Moreover this new state is weak. It does not say who owns the port. I suggest to replace RTE_ETH_DEV_DEFERRED state by an owner string. The owner could be printed or compared with known values. The failsafe PMD would set "failsafe" as owner of its sub-devices. It could also be used by applications to record which ports are used. For instance, testpmd would set the owner as "testpmd" for polled ports. It would bring a new information to DPDK entities: some ports are free. And in the case of multi-process, the PID could be part of the string. About iterating over ports with the macro RTE_ETH_FOREACH_DEV, we should add a string parameter to compare the owner of the ports. The empty string would be an acceptable value to find ports not owned. Note that applications are not forced to make explicit their ownership. We could use the NULL pointer to iterate over all existing ports if needed. I suggest to add two new functions: - rte_eth_dev_owner_set(id, owner) - rte_eth_dev_owner_get(id) Opinions, comments?