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 65A49A04FA; Wed, 8 Jan 2020 10:55:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 02DDE1D682; Wed, 8 Jan 2020 10:55:49 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id C74401D681 for ; Wed, 8 Jan 2020 10:55:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578477346; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bzk4cB9B4nVQvvd1cHecx2w0Jiv+ht5oUM8ztRd9eD8=; b=aQDDeXsCYh7c5fYsavqJktVGJ/Uhq/S5oJF7bHaC4SygMZ3BXDQ1uRXAAE5InP/er7Wqwq njhO2b32L5YZNhzfIt7QaOdvYyyC/fwmJXw/15N48B3fzOD2wuG1cuVeMTD+syU5k2eiO1 mtsJW+YRnUfzsMOWfmSzzqoVk0aN6WY= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-282-EMr6j5FbPu6UddXSAQcJKw-1; Wed, 08 Jan 2020 04:55:43 -0500 Received: by mail-il1-f198.google.com with SMTP id x69so1692160ill.14 for ; Wed, 08 Jan 2020 01:55:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Bzk4cB9B4nVQvvd1cHecx2w0Jiv+ht5oUM8ztRd9eD8=; b=C07C95zJYJGfhCZagzckbYrr3PJN5N/2gxC0goLGqLrloGu4j1wpXjf5Z/SF7H/tLL TLq4YPOULzYq1uUQeA9EF3JKYvwQYHmj9BHs6uiy6l1lkYiItZhvVCSeA1dzAn2MJMYt B0POr9X4lvcS/tmFtPeepwuAvN75vngUIIme0R+03noxYeHqqFgUW1Ynn7tgg/kH/LQX aAWnzQDgrPydWkoXkBySw6afgHk/IWoO8GsNO8xcqsrAiQOR4GBpOva1QxXXdNha/s9y 9SZ06z/Cn9Xtvl9IYthp+9QuDYr1e2u2ThcjMnWoy7oxEgsjZR2PBLSHbUZAbf8QeIyP 8n6Q== X-Gm-Message-State: APjAAAXckS1EORJhSCHD557+r3zPcSkojBRsiJyEFZ/SngD2C+fwxJkE qmK8TAS/75+viVTGjP3oEzO3VVTSVuUb3N795ElyL44nuHSLNOPow8Vbvm9U3M1THoDoesA1U3S zWP3PyjHbt0XKmQGJdG4= X-Received: by 2002:a5d:8889:: with SMTP id d9mr2445093ioo.281.1578477343235; Wed, 08 Jan 2020 01:55:43 -0800 (PST) X-Google-Smtp-Source: APXvYqxhFECa3meSgvPL1Md2eDffIikD9v1xtKjU6biWT7bHDxQWDhYXZx+b9A60r8HN0BoSd4XsZ1MMY26E0D/RMWc= X-Received: by 2002:a5d:8889:: with SMTP id d9mr2445076ioo.281.1578477342859; Wed, 08 Jan 2020 01:55:42 -0800 (PST) MIME-Version: 1.0 References: <20200107145637.8922-1-laurent.hardy@6wind.com> <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> In-Reply-To: <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> From: David Marchand Date: Wed, 8 Jan 2020 10:55:31 +0100 Message-ID: To: Ferruh Yigit , Laurent Hardy Cc: dev , Olivier Matz , Thomas Monjalon , Andrew Rybchenko X-MC-Unique: EMr6j5FbPu6UddXSAQcJKw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 8, 2020 at 10:09 AM Ferruh Yigit wrote= : > > On 1/8/2020 8:56 AM, David Marchand wrote: > > Hello Laurent, > > > > Bonne ann=C3=A9e. > > > > 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 lo= ok > >> 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? -- David Marchand