From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v4 1/3] fm10k: enable FTAG based forwarding
Date: Wed, 02 Mar 2016 14:47:11 +0100
Message-ID: <2271991.zTyknjfr7H@xps13>
References: <1454557129-12825-2-git-send-email-xiao.w.wang@intel.com>
 <1456810601-7419-2-git-send-email-xiao.w.wang@intel.com>
 <20160301143751.710ef28e@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
 by dpdk.org (Postfix) with ESMTP id 19A599AC4
 for <dev@dpdk.org>; Wed,  2 Mar 2016 14:48:47 +0100 (CET)
Received: by mail-wm0-f45.google.com with SMTP id l68so81043393wml.0
 for <dev@dpdk.org>; Wed, 02 Mar 2016 05:48:47 -0800 (PST)
In-Reply-To: <20160301143751.710ef28e@xeon-e3>
List-Id: patches and discussions about DPDK <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>

2016-03-01 14:37, Stephen Hemminger:
> On Tue,  1 Mar 2016 13:36:39 +0800
> Wang Xiao W <xiao.w.wang@intel.com> wrote:
> > +static int
> > +fm10k_check_ftag(struct rte_devargs *devargs)
> > +{
> > +	if (devargs == NULL)
> > +		return 0;
> > +
> > +	if (strstr(devargs->args, "enable_ftag=1") == NULL)
> > +		return 0;
> > +
> > +	return 1;
> > +}
> 
> It is good to see the DPDK keeping up with the leading edge of hardware
> support.
> 
> My issue is that devargs are the Linux module parameters method of
> configuration in the DPDK world.  They are an API only a developer
> would love..
> 
>  1. It has to be done at boot

For vdev it can be done later.
The devargs can be generalized in the driver model to provide a
configuration interface per device.

>  2. Applications have to rewrite (or expect customer) to pass args

Like said above, if the devargs are correctly implemented, there will
be some API to pass them.

>  3. Can't be changed at runtime

Same point as 1.

>  4. Can't be selected on per device basis.

No. The devargs are args per device.
For PCI, they are currently passed in the whitelist.

> Please find a better way.

Another way would be to extend the configuration structures.
I think it's better to re-think the device configuration and the command line
using some devargs and more functions, ops and structs to configure the really
generic stuff.

This devargs goes in the direction of a flexible configuration, so I'd vote +1.