[dpdk-dev] [PATCH v8 00/25] Support VFD on i40e
vincent.jardin at 6wind.com
Wed Jan 11 12:03:42 CET 2017
Please can you list the gaps of the Kernel API?
Le 11 janvier 2017 3:59:45 AM "JOSHI, KAUSTUBH (KAUSTUBH)"
<kaustubh at 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.
>> On Jan 10, 2017, at 3:23 PM, Vincent Jardin <vincent.jardin at 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,
More information about the dev