From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 13AC2A04FA; Wed, 8 Jan 2020 13:27:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3EF3E1D64B; Wed, 8 Jan 2020 13:27:33 +0100 (CET) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id CFEF91D647 for <dev@dpdk.org>; Wed, 8 Jan 2020 13:27:31 +0100 (CET) Received: by mail-wm1-f66.google.com with SMTP id w5so1132767wmi.1 for <dev@dpdk.org>; Wed, 08 Jan 2020 04:27:31 -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=Df3vm1cJe0DLHP+7lX7I0NppbAHsmzh+PO014Inp8Yg=; b=TeL+wFpE0V3hZJxpsLUgJxBIW8fD4nswK6f1//rz43jT9IlsS/iHQ7pLTEo1FQ2Cbw eAGSxfIbGzn/KB+dJ/42OyXyLpjLJaaPT27M3CIGll0THEbiVudeqpff9VbufWhf/bsJ zLATiuZ1zEerDVOLXzb2dXQdLdLHCkyosRulEeCI2VIvbN5V6q5eihTin4J3wyWlb1Wf MV6e+P0lYg2iGNuJ8uCgsepK4ocGSQVB1LMjcGw4g2aM953Cc45150mGVwK7EpCA14TY KmxfX/u85zNYHrBkVn0gPbX9ZIJzVHBLIFF/nYTBOz8gYjskgABmuekvxyIYLdzqRJf0 cYRw== 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=Df3vm1cJe0DLHP+7lX7I0NppbAHsmzh+PO014Inp8Yg=; b=prqroJDWlIKpAGmDhuhx6bV+3kIVdjmH7Wy6/5d70BhazWPE+mINhTEi/V3DzALqQC p9YCVCadP+MQwRgUwFyksc4iiVEFw85KaTkhhfbzPBuvAXIU5KHRS//ytefgBqW19ttf Q8ksDi6ajPY195J814V1RLr4BuxHi8w/XSzrd9J8lMN3WTraxFkF3EPBXDr8kxGKaTl0 R/aPrT6F2L2MVrqcksVrKBwHrYyzVcgCjMPqN/q2I018IIdUNGS+UdwXncAb2O4vGFWV CRXuampBA2/80IMtHkof3JVqmZr4M6rTjXO9OwkBa8KX/MUiMpKHT3lKHYPNK3aku2z8 ffjA== X-Gm-Message-State: APjAAAWqF5P5ilCRniD7LQ7nzUBcxyyxCu9BdS8hl/CCVMjMWgLYgZ+h JsB/BX7frOUx76BGLCU/FibV2Q== X-Google-Smtp-Source: APXvYqyvvQ8QfpHSlKkmi9l+axvE34P6drz5q2tCwqcBSDjwzJkrWs6u+Ym57GRa43VnZY09RzJeoQ== X-Received: by 2002:a1c:1b44:: with SMTP id b65mr3387389wmb.11.1578486451449; Wed, 08 Jan 2020 04:27:31 -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 s65sm3705338wmf.48.2020.01.08.04.27.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 04:27:30 -0800 (PST) Date: Wed, 8 Jan 2020 13:27:30 +0100 From: Olivier Matz <olivier.matz@6wind.com> To: Ferruh Yigit <ferruh.yigit@intel.com> Cc: David Marchand <david.marchand@redhat.com>, Laurent Hardy <laurent.hardy@6wind.com>, dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>, Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <20200108122730.GC22738@platinum> References: <20200107145637.8922-1-laurent.hardy@6wind.com> <CAJFAV8w8K3WaTr40q=ZBX1Y1-7LvwzN2kTT=gdEEnFhCUYcxCQ@mail.gmail.com> <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> <20200108094234.GB22738@platinum> <80003197-42da-23ee-d96d-f0e5d9cecb27@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80003197-42da-23ee-d96d-f0e5d9cecb27@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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Wed, Jan 08, 2020 at 12:12:11PM +0000, Ferruh Yigit wrote: > On 1/8/2020 9:42 AM, Olivier Matz wrote: > > 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 <laurent.hardy@6wind.com> 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. > > What does it mean it is not recoverable, like can you turn on the led but can't > turn off it back? Can't this be fixed in the PMD? In the case there is only one LED, which is by default used to display the link status, it can never display the status again without resetting the device. Maybe an alternative solution would be to add a function, in addition to on() and off(): led_ctrl_status_link() to display the status link on the led. > > > > > Today it is not possible to know if the feature is available without > > side effect. > > >