On 17-01-11 06:51 AM, JOSHI, KAUSTUBH (KAUSTUBH) wrote:
> Also, the kernel drivers have no concept of passing VF messages to upstream
> "decision making” (or policy enforcement) software like VFd.
>
> On Jan 11, 2017, at 9:49 AM, Kaustubh Joshi
> mailto:kaust...@research.att.com>> wrote:
>
> W
, ALEX'
> Subject: Re: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e
>
> Le 10/01/2017 à 22:32, Ferruh Yigit a écrit :
> > What do you think to continue high level DPDK PF discussion in mail
> > thread for other pathset? So that we can continue to work on this one.
&
Also, the kernel drivers have no concept of passing VF messages to upstream
"decision making” (or policy enforcement) software like VFd.
On Jan 11, 2017, at 9:49 AM, Kaustubh Joshi
mailto:kaust...@research.att.com>> wrote:
When Alex from our team started working on Niantic last year, the follow
When Alex from our team started working on Niantic last year, the following
were the list of gaps in the kernel drivers we had a need to fill:
Direct traffic to VF based on more than one outer VLAN tags
Optionally strip on ingress (to PF) and insert on egress VLAN tag
Disable/enable MAC and VLAN
x27;
> ; 'ZELEZNIAK, ALEX'
> Subject: Re: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e
>
> Le 10/01/2017 à 22:32, Ferruh Yigit a écrit :
> > What do you think to continue high level DPDK PF discussion in mail
> > thread for other pathset? So that we can continue to
On 1/11/2017 1:14 PM, Vincent JARDIN wrote:
> Le 10/01/2017 à 22:32, Ferruh Yigit a écrit :
>> What do you think to continue high level DPDK PF discussion in mail
>> thread for other pathset? So that we can continue to work on this one.
>
> First, we need to assess or not if it makes sense to go t
> -Original Message-
> From: Vincent Jardin [mailto:vincent.jar...@6wind.com]
> Sent: Wednesday, January 11, 2017 7:04 PM
> To: JOSHI, KAUSTUBH (KAUSTUBH)
> Cc: Zhang, Helin; Lu, Wenzhuo; dev@dpdk.org; DANIELS, EDWARD S
> (EDWARD); ZELEZNIAK, ALEX
> Subject: Re: [d
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
Le 10/01/2017 à 22:32, Ferruh Yigit a écrit :
What do you think to continue high level DPDK PF discussion in mail
thread for other pathset? So that we can continue to work on this one.
First, we need to assess or not if it makes sense to go toward Linux
kernel or DPDK based PF. If Linux kernel
Please can you list the gaps of the Kernel API?
Thank you,
Vincent
Le 11 janvier 2017 3:59:45 AM "JOSHI, KAUSTUBH (KAUSTUBH)"
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
Hi Vincent,
On 1/10/2017 8:23 PM, Vincent Jardin 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
> duplicatin
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 regard
Acked-by: Helin Zhang
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 10, 2017 3:16 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e
>
> 1, VF Daemo
1, VF Daemon (VFD)
VFD is an idea to control all the VFs from PF.
As we need to support the scenario kernel PF + DPDK VF,
DPDK follows the interface between kernel PF + kernel
VF.
We don't want to introduce too many new messages
between PF and VF.
So this patch set adds some new APIs to control VFs
14 matches
Mail list logo
