From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [PATCH v5 23/29] app/testpmd: handle i40e in VF VLAN
 filter command
Date: Mon, 19 Dec 2016 11:13:18 +0000
Message-ID: <72f4a443-7116-b00f-85e1-c7792a010fee@intel.com>
References: <20161216143919.4909-1-ferruh.yigit@intel.com>
 <20161216190257.6921-1-ferruh.yigit@intel.com>
 <20161216190257.6921-24-ferruh.yigit@intel.com>
 <4ab71f12-5352-fa36-3691-929c8a2b8bbf@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: Jingjing Wu <jingjing.wu@intel.com>, Helin Zhang <helin.zhang@intel.com>,
 Bernard Iremonger <bernard.iremonger@intel.com>
To: Vincent JARDIN <vincent.jardin@6wind.com>, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 7B773F925
 for <dev@dpdk.org>; Mon, 19 Dec 2016 12:13:23 +0100 (CET)
In-Reply-To: <4ab71f12-5352-fa36-3691-929c8a2b8bbf@6wind.com>
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>

On 12/16/2016 8:31 PM, Vincent JARDIN wrote:
> Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
>> +#ifdef RTE_LIBRTE_IXGBE_PMD
>> +	if (strstr(dev_info.driver_name, "ixgbe") != NULL)
>> +		ret = rte_pmd_ixgbe_set_vf_vlan_filter(res->port_id,
>> +				res->vlan_id, res->vf_mask, is_add);
>> +#endif
>> +#ifdef RTE_LIBRTE_I40E_PMD
>> +	if (strstr(dev_info.driver_name, "i40e") != NULL)
>> +		ret = rte_pmd_i40e_set_vf_vlan_filter(res->port_id,
>> +				res->vlan_id, res->vf_mask, is_add);
>> +#endif
> 
> That's exactly what we need to avoid, it won't scale to many PMDs.
> 

For a generic PMD feature, completely agree with you. Application
shouldn't know/worry about underlying hardware. eth_dev layer should be
used.
But above usage is for an application that knows the hardware, and
knowing that it is losing all the benefits of the portability and
explicitly including the PMD header to use those PMD specific APIs.

Thanks,
ferruh