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

[Zhang, Helin]

> -----Original Message-----
> From: Vincent Jardin [mailto:vincent.jardin at 6wind.com]
> Sent: Wednesday, January 11, 2017 7:04 PM
> To: JOSHI, KAUSTUBH (KAUSTUBH)
> Cc: Zhang, Helin; Lu, Wenzhuo; dev at dpdk.org; DANIELS, EDWARD S
> (EDWARD); ZELEZNIAK, ALEX
> Subject: Re: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e
> 
> 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 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.
> >
> > Regards
> >
> > KJ
> >
> >
> >> 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.
As a PF host driver is not new to DPDK. From very early igb and ixgbe were
developed to be a PF host driver, then i40e.
In addition, I guess Linux kernel community does not like entire DPDK at all.
For now, the VFD features is added in the PMD itself, which does not require
all PMD to enable that.
I'd suggest to treat it as an experiment feature to keep it in the specifical PMD,
until it is popular enough and mature enough, then we can think about adding
it to ethdev layer as generic features for all PMDs.
This type of feature can help to address the real needs of at&t, who is the
pioneer of this feature. Having a real user of a feaure might be a good
reason to try this way.

Regards,
Helin

> >>
> >> Best regards,
> >> Vincent
> >>
> >>
> >
>