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 50844A04F3; Wed, 8 Jan 2020 16:16:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5D4251D40F; Wed, 8 Jan 2020 16:16:29 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id DAFAA1D14D for ; Wed, 8 Jan 2020 16:16:28 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id j42so3712383wrj.12 for ; Wed, 08 Jan 2020 07:16:28 -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=D4z6LrM5G8WaRPbW8ilMIlvDMbHntJ5M8xQiXFR8dCE=; b=gm8jcaYUL1FWz0+M6jgd3q4i4D9BcLS3JF1J2B+SIzDfaqHZphvON0tmUpa5bykOoM nquAz97gPxSY235pA5FOroMVMn77rBKj5ngmlKW+iEmvxgPim0+iqUq7nJn7DbIuRMEJ 1bgkgPV132vzGhP6w4gmEDqU/55kH1WwnjwmCoa5pDm6GNamSyOAmIrACdMITdITVNTP LMmstZYoPFVl9MyvXfdXhk98GhI2oXKjgeruCoIho9S8eeri+1Y52J8Sm6Ls3kK4gnoH l/Dfq9C19TuLGrzPX86o/ebxhXmSXknIXWBgEzG3y91GDrCBv+34THnxcpPW6mxgQ8gx hSew== 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=D4z6LrM5G8WaRPbW8ilMIlvDMbHntJ5M8xQiXFR8dCE=; b=B6z4WYf1D+sroQ3Opod4qqxAEXb0CrpGPMTAzMDYa/bbX7kn3Yrpi/87aG68M7BYiP DD/PIWKrbiczlIE0HWbid4ll7mSgz+69VpeddN32h3qvgLbPe5BnJFHt1vcu3C/z1dnN /ctJl+mR6VS81bCr6lWDvu5Qs7JnPvdB8P1+dtXBpi3MKT2AcZW4QnD+M9JpKi5gr49r 7VWsRn5py1mIvjCfLP+aGkT5OTIg1ZS25lSwUX3b4UHD9FGEBtdjw127ShWgRJfo8Dml kLCpE7D6Fi5i/xgvOHLlEA2YtVUrQ+MfjRJWeuBnnayLihFRLt/fJ4JNqkR3wyk2QYUr Rk4Q== X-Gm-Message-State: APjAAAVzwz3lSB0PXedXQqMvCUDnZfzaZ8dTqQ01hQONVxQ4Stp9FZbO LrvYSYSOtOrrlRgroJl+z08f2Q== X-Google-Smtp-Source: APXvYqyOnRRZqM/8dk41MAyleGS2eKf3u//2SA8RA5WITOYFuuBLiqxFp0XNqsWUJlFq07GR1HDkwg== X-Received: by 2002:adf:f78e:: with SMTP id q14mr5132002wrp.186.1578496588563; Wed, 08 Jan 2020 07:16:28 -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 u16sm4165991wmj.41.2020.01.08.07.16.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 07:16:28 -0800 (PST) To: Thomas Monjalon , David Marchand , Ferruh Yigit Cc: dev , Olivier Matz , Andrew Rybchenko References: <20200107145637.8922-1-laurent.hardy@6wind.com> <1825898.usQuhbGJ8B@xps> <9e05c21a-dfa9-4ac8-0937-38394b25dac0@6wind.com> <1709381.atdPhlSkOF@xps> From: Laurent Hardy Message-ID: Date: Wed, 8 Jan 2020 16:16:27 +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: <1709381.atdPhlSkOF@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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:07 PM, Thomas Monjalon wrote: > 08/01/2020 14:58, Laurent Hardy: >> About the 'is_supported()' versions of APIs, in the current patch I >> factorize >> the check on dev ops on and off availability in a same function named >> "led_ctrl_capable" but I can rename it if required. >> >> Just in this specific case I don't dissociate on and off capability, as >> being >> able to set the led off without a way to set it on again sounds a bit >> unusual :) >> >>> The other alternatives are in rte_eth_dev_info and dev_flags. > Basically we just need to decide whether we prefer a new function > or a new flag. > > Until now, capabilities were given in flags. > Why a function here? > For this case, (led control API) all material is already available at rte_ethdev layer. So you could rely on led_off/on ops availability without the need to add/maintain in all pmds some flags to expose such capabilities. What do you suggest to set a capability flag for the device at rte_ethdev level?