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 4FAF6A04FA; Wed, 8 Jan 2020 14:00:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2D1CE1D6FF; Wed, 8 Jan 2020 14:00:59 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id E42B41D6E7 for ; Wed, 8 Jan 2020 14:00:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578488457; 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=BETrbIdy98/VG28VPcm81LxANTdPSE+8SHwe2T2j/DY=; b=izCrQNjnkq7BqLvNpWngnH6hxUtDn0sNUOHwYSpo21Tk3xFztsDaEAgqitbfZxT+qIlj4Y KwLkYPMSBQJy+zGjNB60pIjcv4IliyQ4Y+rRC+sGJAuA03EfujrtvPYSPW92sL4sfK8lUe Ta8NhxQB1ckmvGYvnE5XZ7yXwKxmj4A= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-328-w8pNOE4qP-SjUa5DZPfFQw-1; Wed, 08 Jan 2020 08:00:55 -0500 Received: by mail-ua1-f72.google.com with SMTP id 71so596093uae.22 for ; Wed, 08 Jan 2020 05:00:55 -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; bh=7jyJaMF+vz7OihH9fR+Wk2Yle5PbHSAvPE0vkAFGWL8=; b=LSSaEctbWmQmFADjW7jS4SH2gXz0by+dvRZxjNnR7vVjcaBb3fxULv1pGCPRdk0hWO LawmHvaUyEWKIG6n5mUyn6dLKGlTuZeg0tRsd8oMY2UT2GneKr98vaR/WizNIKBJt37S OgElqUdCUfqDEFrTukCNZr0/21CsDGJusMy7ZiLKEciWQI3JVsn13Jkr5i8sHyrxTJpa FseC0hZLw7XBkad5Dc1tuj10LQE2A9NqASNxhcn2Kh21E4/xH7kJko0OBZlhMyNL2GAb s1WlbFh7AKq8KcbYZ+yfcPyEtegyPNmS2jPSXcas/g9Z1To52GukpOmJBiZIgP4Mwtnu bHHw== X-Gm-Message-State: APjAAAVXnZZDG9hYrJ5QuXUx0vSe2i10jYxIkAK35opsH4GJi/SnuX8c NVVXTco95nEdTpvYZg12I89cTFlJhFQoIKqP2kquaeSRjLI21XQaL1+FTjd9lHb4RCXnLszfyCu 6T34oWwde6vuGJ+dnHUA= X-Received: by 2002:a1f:fe4e:: with SMTP id l75mr2876747vki.18.1578488454884; Wed, 08 Jan 2020 05:00:54 -0800 (PST) X-Google-Smtp-Source: APXvYqz8NTzIyHqel9Ff9gXFO9Ely7cXAxuKpiqHEuqUzKlq8RNEc2wjUI3fBU2Wdw9HNo0murgDuKj3CAo0bGTtRrI= X-Received: by 2002:a1f:fe4e:: with SMTP id l75mr2876727vki.18.1578488454528; Wed, 08 Jan 2020 05:00:54 -0800 (PST) MIME-Version: 1.0 References: <20200107145637.8922-1-laurent.hardy@6wind.com> <2b1389a4-98ec-49cc-b2d0-2e38690fcf4b@intel.com> <27a90969-0241-00e0-0748-b6c6327ab4db@intel.com> In-Reply-To: <27a90969-0241-00e0-0748-b6c6327ab4db@intel.com> From: David Marchand Date: Wed, 8 Jan 2020 14:00:43 +0100 Message-ID: To: Ferruh Yigit Cc: Laurent Hardy , dev , Olivier Matz , Thomas Monjalon , Andrew Rybchenko X-MC-Unique: w8pNOE4qP-SjUa5DZPfFQw-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 1:30 PM Ferruh Yigit wrote: > On 1/8/2020 9:55 AM, David Marchand wrote: > > On Wed, Jan 8, 2020 at 10:09 AM Ferruh Yigit w= rote: > >> 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 is good point, perhaps we should add a comment to that line to highl= ight it. The comment won't help in the CI checks. Not talking about short term, but could we consider separating the inlined ops from the rest (pushing them to rte_eth_dev ?) ? We would then hide completely eth_dev_ops at the next ABI break window. -- David Marchand