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 2FC83A04F3; Wed, 8 Jan 2020 15:45:14 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E8ACE1DA58; Wed, 8 Jan 2020 15:45:13 +0100 (CET) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 0B3841DA55 for ; Wed, 8 Jan 2020 15:45:12 +0100 (CET) Received: by mail-wm1-f67.google.com with SMTP id p9so2764688wmc.2 for ; Wed, 08 Jan 2020 06:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=buQymDBQLYo44h8hxP6CvZqZXRNKmWQSF6yRiqnK5v0=; b=D7KAqlx6jg4VI7cCHAuEgDhvdeWmc3VaCJNu9tIWyeCuBudyssuSvlgpYA7ZsYKQo5 pu4u2yAXAAn1NfKjPMibbpaifohlaCXlVZJDIE3Bj0yCXhCAcfEf1L5cZhf2yERCGdsF VRcpaBGIYdJCSO8WNd2OwA6WbkUsYBnGMtOsQ82zmix0YUVTvWqx4WCr4qE8CWO8tEgC xRnOmATTFQ5Jvzoy2Wuv4L7a4S98wzuaxlw70PjR5hzAc9ZFrkSgcHVKcsLPwJaM8vlg p9AbWJIeEuQbh/R2x9lgmbXPYj0hxm72Ae2a+l3IY38ziISRlrrYo/RnUVZ9MOiBXeoP t82w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=buQymDBQLYo44h8hxP6CvZqZXRNKmWQSF6yRiqnK5v0=; b=lGPjMeSFqZwwPPMk1tOFdsSbr9FQ5rYVQd3JOdh0CgXoOFOui/aVuDTFC8mCqsJ6em VTqMoQbCVb5MEj2sl6T7MF8PTnHDryeZ3m1QTy0l2klf33y0dbBmxsK8IKYYAimVxmaJ ynsYGhmN8G4p6FOMzuRbFs7mIm0jDBdUc7gTuyPuHn2FQqrLgkUE8UZNFTFGu+VmZU6v nTbwfFMMS5U2vdMGcPcpQcQqz/RDm4EyIBppGLjYRsh0EUhzPPMGSznm2t6idr2HoiJ1 a3bL5HemZXCZKHGwR2eqTj/Any13fmx+/cg15sr34DwVX3ji1PkbaquYLPoSPDX/U0wP ms8Q== X-Gm-Message-State: APjAAAV4yimP1xMvLFZRX6Tx3m9KfbOKGQeHmr2E32wOnLX1syakdGtF 3uzwCj3G+8I8Rh7/EkHO7Si28A== X-Google-Smtp-Source: APXvYqw+V28XhYgg3tFEKsug8e62obF09uymtndQyuYanM219QyARidByARyP0J+DfuKPysjdPeUUg== X-Received: by 2002:a05:600c:211:: with SMTP id 17mr4309898wmi.60.1578494711775; Wed, 08 Jan 2020 06:45:11 -0800 (PST) Received: from [10.16.0.207] (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.googlemail.com with ESMTPSA id 124sm3101065wmc.29.2020.01.08.06.45.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 06:45:11 -0800 (PST) To: Ferruh Yigit , Olivier Matz Cc: David Marchand , dev , Thomas Monjalon , Andrew Rybchenko References: <20200107145637.8922-1-laurent.hardy@6wind.com> <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> <20200108094234.GB22738@platinum> <80003197-42da-23ee-d96d-f0e5d9cecb27@intel.com> <20200108122730.GC22738@platinum> <38a003af-48b9-058b-5d65-cb5f2b123d78@intel.com> From: Laurent Hardy Message-ID: <66eaf121-00ed-2b1c-8808-68d172667700@6wind.com> Date: Wed, 8 Jan 2020 15:45:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <38a003af-48b9-058b-5d65-cb5f2b123d78@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 1/8/20 3:08 PM, Ferruh Yigit wrote: > On 1/8/2020 12:27 PM, Olivier Matz wrote: >> 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 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. > Is there a specific PMD are we talking about? e1000 pmd which seems to have different behavior according to the nics used (at least it has been reported using i210 and i350 copper). > >> 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. >>>>