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 C826FA04FA; Wed, 8 Jan 2020 11:31:23 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 082181D9B5; Wed, 8 Jan 2020 11:31:23 +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 8CD8D1D731 for ; Wed, 8 Jan 2020 11:31:21 +0100 (CET) Received: by mail-wm1-f66.google.com with SMTP id d139so16184399wmd.0 for ; Wed, 08 Jan 2020 02:31:21 -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=4xHj+DeK6nbqDJILqSWo5XsaOWPbBI8eaJrIwMpz3CI=; b=Mn0oVt5aa6bGlqeFOP9cDMkUnSLzd8tqy3ZcQMG7jfj4jC1bXKgaAhCHCZhCVdBvs+ VkqC7ggjiAu08sQqF0Y7W6oa2NnqWQp4COERvNh3Le7qiYkYQgZWvprH3Wjmu8d88slT TMAY/i7qwH4uMEohMNM1RRWFxzFykTboMEuqZP5UctKMxlka7LGw4JvIgud9aRNP4e5Z /GS9HalVCG8bFrtchoKxnQx8x3SoVosGMsgTDtmI+VrTSh3/DOCLB/6kPGuh2Ie62odz cCtQg13Ei7asv+kMDbWTIhfj0xNZVzsCK5Nbq9b1bOmo0AyUW8liFDOwU4uP2FD+8Uh1 HzZw== 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=4xHj+DeK6nbqDJILqSWo5XsaOWPbBI8eaJrIwMpz3CI=; b=ovBuTQjlZekbehf7JgjgFUrhoppl9asgT1lqg/oTIQ4/ALVTOKkC6IHJxLm3oSsUrE Qk0Xjqn33HEIV/Oc9bOhKahil6++/fH3pPYknKO5050KDM39+8edgeO8cE7OGxNpmtbc 5dW2kOzlf4j7udGANlzP6MXGrxF3PZ6B0zKoYH6umDwvAePLryj/7dZjrV/A63o1CovY Uu3ZVDI1xUwF8+7ZqKrHbbyiGQ3NMMs1nINiF+RcAzEgRJHv5yNXO/Pq9X0xODco46aL 340186bhrgkBJCY1GFNJIlxoFOaGU8qgJdSOya7nz0WxaodE9P7okrNLjmrAHbfi5mqI e2vg== X-Gm-Message-State: APjAAAUyM26GWL2ib9/wX9hsMwPRd0OSq5oAlHqpzPrf/GLvzq8IZwlW hErD/ILe0scfjRgsKYOCBascjA== X-Google-Smtp-Source: APXvYqzPzHFeZr5dma/9DC8WJv1zeql0HsEGRSLRcEEkLlBSiF/91oLEeUtb1Yk4LQbT6AGu42nvng== X-Received: by 2002:a05:600c:28d:: with SMTP id 13mr2846874wmk.52.1578479481180; Wed, 08 Jan 2020 02:31:21 -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 o16sm3410841wmc.18.2020.01.08.02.31.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 02:31:20 -0800 (PST) To: David Marchand , Ferruh Yigit Cc: dev , Olivier Matz , Thomas Monjalon , Andrew Rybchenko References: <20200107145637.8922-1-laurent.hardy@6wind.com> <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> From: Laurent Hardy Message-ID: <4b86e1d8-9c25-ce7c-f5f4-124c63a7c8b0@6wind.com> Date: Wed, 8 Jan 2020 11:31:20 +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: 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" Hi all, On 1/8/20 10:55 AM, David Marchand wrote: > On Wed, Jan 8, 2020 at 10:09 AM 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. > You are right. > So in our context, this is not an ABI breakage. > But abidiff still reports it, so maybe some filtering is required to > avoid this false positive. > > Note that if we insert an ops before rx_queue_count, we would have a > real ABI breakage, as this ops is accessed via an inline wrapper by > applications. > > >>> 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? > You might want to know it is supported without changing the state. > Laurent? First, happy new year :) Yes exactly, the purpose of this patch is to query if the device is led control capable or not without changing the led state. About exposing the capability through a dev_flags, means to make some modification in each pmds. It looks more easy in term of pmds maintenance to relying on the rte_eth_led_off()/on() dev ops availability at rte_ethdev level, right ? > > > -- > David Marchand > >