From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: [PATCH v1 0/8] Bus control framework
Date: Mon, 11 Dec 2017 17:23:55 +0530
Message-ID: <427aa68d-b21b-eb78-9ecd-f796260eb6d7@nxp.com>
References: <cover.1507796085.git.gaetan.rivet@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <dev@dpdk.org>
To: Gaetan Rivet <gaetan.rivet@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam03on0043.outbound.protection.outlook.com [104.47.41.43])
 by dpdk.org (Postfix) with ESMTP id CDE9E2030
 for <dev@dpdk.org>; Mon, 11 Dec 2017 12:40:23 +0100 (CET)
In-Reply-To: <cover.1507796085.git.gaetan.rivet@6wind.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hello Gaetan,

(I am assuming that this series is still valid for 18.02 and you will 
spin a new version of this.)

On Thursday 12 October 2017 01:48 PM, Gaetan Rivet wrote:
> Probing policy was introduced in the previous release as a configuration item.
> It was thus added to the generic bus structure, breaking its ABI.
> 
> In this release, the IOVA mode can be read from a bus to configure the
> EAL. This new configuration element also broke the bus ABI when it was
> added.
> 
> As new operators had to be implemented for the probe policy item, these
> patches were developed to help mitigate this issue.
> 
> This control framework allows to expand the rte_bus API without breaking
> its ABI. It is meant to be used with configuration elements that may
> only be valid for a few buses, while the others would remain untouched
> and unaware of the evolution.
> 
> A central control operator is used, similarly to the working of rte_flow
> API in the ether layer. Each driver thus chooses to expose a set of
> operators relevant to its implementation. The caller is then free to use
> those if they are available.

I like the overall idea - similar to an ioctl.
It would help extend the control knobs of buses (drivers?) without 
adding additional dependency on ABI/API.

+1

> 
> Both Probe mode and IOVA mode operators are implemented for the PCI bus. >
[...]