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 12459A04FA; Wed, 8 Jan 2020 10:42:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 55E4B1D5D1; Wed, 8 Jan 2020 10:42:37 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 835F11D5B2 for ; Wed, 8 Jan 2020 10:42:36 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id c9so2590176wrw.8 for ; Wed, 08 Jan 2020 01:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=P9gkAmc9X+aeNW96z4NsMIWZyFHd+PcrJgGLyLT0CFw=; b=AN9nhiIJlXxP1VwDn0MvSFyE4rukdelIdcQO+x80BlSfMMWyhMhrdCYYlqo2sRQ46n HK0nSK++d3dRRKoWzDt3skNUBhqj4Un0sZCBmiYGo1I2hQ7EB5LexkcC7q5jnzKpygXV t9OZFJlI5xpbXXfOv5ID0Gez0aDrRsrf/EayKP+DRkRZ1EW+IGisPdzzjxWfiSw60py9 2aVxlNHQ9bZqxrTHn71hSqdqwApTGV2kd8SkXXr8E3UrjaZ3UwlAIPK4b7Bkx9vwVj7p nAwi3DDFK1JUiYj8yZn8q51Alo06izW9obQw1ahOHEZybOqiSi8OBEUGVlbLvO7z4YI5 Nwlw== 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=P9gkAmc9X+aeNW96z4NsMIWZyFHd+PcrJgGLyLT0CFw=; b=UQPdaQx/4Amyx9A5C2Dle9uZiibZklt7+oaZ/7tXw6eRCg5C2mMfa1xeuBkWl0wihM JcoIPAlxpinNktYdQP3cv1v+qeofrknJrsfelWLHSXBihQKNdBexm7j50br8ZMeevLqQ huO6NQslaID6jEDcN5LoQzrzs2X7NCSj8WvourrU8P2dah8T1fsc6YHZ0hfpo8G++Aqc H5B62fPUQP8qipoDThoa04VW+TAMH6Z7osqQYPWYeOWlKmayM1hiO2zpeuBh4GEFZQX6 AdJ+2/Wbl2jWCvL06drYivwPx1O+hdl97dJ56ee1ssQAx/DZfmoQYwkdQjzRnduJ4wZz 49Bw== X-Gm-Message-State: APjAAAUsAGK1T4ao5AFZCPQcd+306gBaaDxt2n5viaRUUfaR9EbhOTdT FglPO8hUEu2xSnIAfKbXEZauceE4IEU= X-Google-Smtp-Source: APXvYqzk5XfRTvvCuGIpNgjv4v7dmEfzhiymMMo2m9PX4ooZwmDDDPqnJiec2wa0OWVdKDxn6SBVNw== X-Received: by 2002:a5d:4847:: with SMTP id n7mr3476740wrs.30.1578476556205; Wed, 08 Jan 2020 01:42:36 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id n3sm3174066wmc.27.2020.01.08.01.42.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 01:42:35 -0800 (PST) Date: Wed, 8 Jan 2020 10:42:34 +0100 From: Olivier Matz To: Ferruh Yigit Cc: David Marchand , Laurent Hardy , dev , Thomas Monjalon , Andrew Rybchenko Message-ID: <20200108094234.GB22738@platinum> References: <20200107145637.8922-1-laurent.hardy@6wind.com> <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH] librte_ethdev: extend dpdk api led control to query capability 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" On Wed, Jan 08, 2020 at 09:09:29AM +0000, Ferruh Yigit wrote: > On 1/8/2020 8:56 AM, David Marchand wrote: > > Hello Laurent, > > > > Bonne année. > > > > Cc: maintainers. > > > > On Tue, Jan 7, 2020 at 3:57 PM Laurent Hardy wrote: > >> > >> In current led control API we have no way to know if a device is able > >> to handle on/off requests coming from the application. > >> Knowing if the device is led control capable could be useful to avoid > >> exchanges between application and kernel. > >> Using the on/off requests to flag if the device is led control capable > >> (based on the ENOSUP returned error) is not convenient as such request > >> can change the led state on device. > >> > >> This patch adds a new function rte_eth_led_ctrl_capable() that will look > >> for led_off/on dev ops availability on the related pmd, to know if the > >> device is able to handle such led control requests (on/off). > > > > This patch breaks the ABI, which is BAD :-). > > Why it is an ABI break, dev_ops should be between library and drivers, so it > should be out of the ABI concern, isn't it. > > > This new api only needs to look at the existing ops, so you can remove > > the (unused in your patch) dev_led_ctrl_capable ops. > > > > OTOH, would it make sense to expose this capability in dev_flags? > > > > 'rte_eth_led_on()' & 'rte_eth_led_off()' APIs returns '-ENOTSUP' when the not > supported, can that help application to understand? In our case, it is not possible to use rte_eth_led_on/off() to check if the feature is supported: on success, it would change the value of the led, and it seems it is not recoverable on some drivers. Today it is not possible to know if the feature is available without side effect.