Re: [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e

From: "Chen, Jing D" <jing.d.chen@intel.com>
To: Vincent JARDIN <vincent.jardin@6wind.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Wu, Jingjing" <jingjing.wu@intel.com>,
	"Zhang, Helin" <helin.zhang@intel.com>
Subject: Re: [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
Date: Mon, 19 Dec 2016 09:01:09 +0000	[thread overview]
Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C5B7FE2@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <5846f66b-9a83-faa6-3de1-c7ae12236201@6wind.com>

Hi, Vincent,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Saturday, December 17, 2016 4:36 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Zhang, Helin <helin.zhang@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on
> i40e
> 
> Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
> > As we need to support the scenario kernel PF + DPDK VF,
> > DPDK follows the interface between kernel PF + kernel VF.
> 
> Please, it has to be proven that DPDK provides the same interface that
> the kernel. It seems insane to duplicate kernel's PF into the DPDK
> without a strong guarantee that it is a strict same behaviour. For instance,
>    - what will happen when the DPDK's PF will have a new feature which
> is not into the kernel?
>    - what will happen when the Kernel's PF will have a feature with
> different capabilities that the kernel?
> 
> Please, make it clear before. Currently, for me it is a nack of this serie.
> 
Let me try to explain.
When we DPDK developed i40e drivers several years ago,  we found the API and
data structures defined in shared code for VF and PF device communication can
satisfy DPDK's requirements, so we just followed that API.  At that time, we'll try 
to satisfy 3 scenarios.
1. Linux PF + Linux VF : it's not our scope.
2. Linux PF + DPDK VF: there is no problems observed since we use same API.
3. DPDK PF + DPDK VF: that's fully under control.
The only scenario was not considered is DPDK PF + Linux VF.

Since then, both Linux and DPDK keep developing code. Then, we found it's
necessary to extend VF capability (Like promiscuous mode). It will be hard to
ask Linux PF to support that service considering upstream effort in Linux world.
So, supporting it in scenario of DPDK PF + DPDK VF became best candidate. But 
how can VF identify who is serving it then decide if extended request can be dispatched?
So, DPDK PF will send a special version number for this purpose.

As time passed by, we realized there some use case for DPDK PF + Linux VF and it's not
supported yet. Then, we found our implementation in DPDK PF is not complete since we
only had considered how to serve DPDK VF at that time. So, we need some improvement
on the PF host driver. Besides that, 'send a special version' to VF doesn't work now since
Linux VF can't interpret the version info. So, we behave the same as Linux PF driver with
sacrifice of extended function in DPDK VF. 

Let me summary the chang here.
1. We shared the same interface with Linux driver from beginning. 
2. This change will support both Linux VF and DPDK VF.
3. We'll find a way for DPDK VF identifying who is serving it so it can use extended function
in future release.