Hi,

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Wednesday, March 2, 2016 6:38 AM
To: Wang, Xiao W <redacted>
Cc: Chen, Jing D <redacted>; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4 1/3] fm10k: enable FTAG based forwarding

On Tue,  1 Mar 2016 13:36:39 +0800
Wang Xiao W [off-list ref] wrote:

quoted

+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..

DPDK supports passing string parameter (devargs) for every pci device to EAL, it's like:
"./test -w 84:00.0,enable_ftag=1 -w 86:00.0,enable_ftag=1 -c f -n 4".
We have discussed (in v3) on how to configure the specific feature for fm10k (by means
of adding a build time config option, or changing the common ethdev structure,
or changing the mbuf structure), neither adding extra build config option nor
changing the common structure looks satisfactory, and we think using devargs is
a good enough solution.

 1. It has to be done at boot
 2. Applications have to rewrite (or expect customer) to pass args  3. Can't be
changed at runtime  4. Can't be selected on per device basis.

Customers configure the FTAG feature according to their need.
We just parse the devargs at dev_start and set FTAG flag for RX/TX queues, we
(or the customers) needn't to change the devargs at runtime.
In DPDK devargs is designed for each pci device, each device has its own pointer
for devargs structure.

Thank you for the comment.

Best Regards,
Xiao