Re: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e

[Vincent Jardin <vincent.jardin@6wind.com>]

Please can you list the gaps of the Kernel API?

Thank you,
  Vincent


Le 11 janvier 2017 3:59:45 AM "JOSHI, KAUSTUBH  (KAUSTUBH)" 
<kaustubh@research.att.com> a écrit :

> Hi Vincent,
>
> Greetings! Jumping into this debate a bit late, but let me share our point 
> of view based on how we are using this code within AT&T for our NFV cloud.
>
> Actually, we first started with trying to do the configuration within the 
> kernel drivers as you suggest, but quickly realized that besides the 
> practical problem of kernel upstreaming being a much more arduous road 
> (which can be overcome), the bigger problem was that there is no 
> standardization in the configuration interfaces for the NICs in the kernel 
> community. So different drivers do things differently and expose different 
> settings, and no forum exists to drive towards such standardization. This 
> was leading to vendors have to maintain patched versions of drivers for 
> doing PF configuration, which is not a desirable situation.
>
> So, to build a portable (to multiple NICs) SRIOV VF manager like VFd, DPDK 
> seemed like a good a forum with some hope for driving towards a standard 
> set of interfaces and without having to worry about a lot of legacy baggage 
> and old hardware. Especially since DPDK already takes on the role of 
> configuring NICs for the data plane functions anyway - both PF and VF 
> drivers will have to be included for data plane usage anyway - we viewed 
> that adding VF config options will not cause any forking, but simply flush 
> out the DPDK drivers and their interfaces to be more complete. These APIs 
> could be optional, so new vendors aren’t obligated to add them.
>
> Furthermore, allowing VF config using the DPDK PF driver also has the side 
> benefit of allowing a complete SRIOV system (both VF and PF) to be built 
> entirely with DPDK, also making version alignment easier.
>
> We started with Niantic, which already had PF and VF drivers, and things 
> have worked out very well with it. However, we would like VFd to be a 
> multi-NIC vendor agnostic VF management tool, which is why we’ve been 
> asking for making the PF config APIs richer.
>
> Regards
>
> KJ
>
>
>> On Jan 10, 2017, at 3:23 PM, Vincent Jardin <vincent.jardin@6wind.com> wrote:
>>
>> Nope. First one needs to assess if DPDK should be intensively used to 
>> become a PF knowing Linux can do the jobs. Linux kernel community does not 
>> like the forking of Kernel drivers, I tend to agree that we should not keep 
>> duplicating options that can be solved with the Linux kernel.
>>
>> Best regards,
>> Vincent
>>
>>
>