DPDK patches and discussions
 help / color / mirror / Atom feed
* Re: [dpdk-dev] DPDK Features for Q1 2015
@ 2014-10-22 15:36 Zhu, Heqing
  0 siblings, 0 replies; 4+ messages in thread
From: Zhu, Heqing @ 2014-10-22 15:36 UTC (permalink / raw)
  To: Zhou, Danny, Thomas Monjalon (thomas.monjalon@6wind.com),
	O'driscoll, Tim
  Cc: Fastabend, John R, dev, Ronciak, John



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Liang, Cunming
> Sent: Wednesday, October 22, 2014 8:06 AM
> To: Zhou, Danny; Thomas Monjalon; O'driscoll, Tim
> Cc: dev@dpdk.org; Fastabend, John R; Ronciak, John
> Subject: Re: [dpdk-dev] DPDK Features for Q1 2015
> 
> > >
> > > This design allows to keep the configuration code in one place: the
> kernel.
> > > In the meantime, we are trying to add a lot of code to configure the
> > > NICs, which looks to be a duplication of effort.
> > > Why should we have two ways of configuring e.g. flow director?

[heqing] There will be multiple choices for DPDK usage model if/after this feature is available, 
the customer can choose the DPDK with or without the bifurcated driver. 

> [Liang, Cunming] The HW sometimes provides additional ability than existing
> abstraction API.
> On that time(HW ability is a superset to the abstraction wrapper, e.g. flow
> director), we need to provide another choice.
> Ethtools is good, but can't apply anything supported in NIC.
> Bifurcated driver considers a lot on reusing existing rx/tx routine.
> We'll send RFC patch soon if kernel patch moving fast.
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhou, Danny
> > Sent: Wednesday, October 22, 2014 10:44 PM
> > To: Thomas Monjalon; O'driscoll, Tim
> > Cc: dev@dpdk.org; Fastabend, John R; Ronciak, John
> > Subject: Re: [dpdk-dev] DPDK Features for Q1 2015
> >
> > Thomas,
> >
> > In terms of the bifurcated driver, it is actually the same thing.
> > Specifically, the bifurcated driver PMD in DPDK depends on kernel
> > code(af_packet and 10G/40G NIC) changes. Once the kernel patches are
> > upstreamed, the corresponding DPDK PMDs patches will be submitted to
> > dpdk.org. John Fastabend and John Ronciak are working with very
> > closely to achieve the same goal.
> >
> > -Danny
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
> Monjalon
> > > Sent: Wednesday, October 22, 2014 10:21 PM
> > > To: O'driscoll, Tim
> > > Cc: dev@dpdk.org; Fastabend, John R; Ronciak, John
> > > Subject: Re: [dpdk-dev] DPDK Features for Q1 2015
> > >
> > > Thanks Tim for sharing your plan.
> > > It's really helpful to improve community collaboration.
> > >
> > > I'm sure it's going to generate some interesting discussions.
> > > Please take care to discuss such announce on dev list only.
> > > The announce@dpdk.org list is moderated to keep a low traffic.
> > >
> > > I would like to open discussion about a really important feature,
> > > showed last week by John Fastabend and John Ronciak during LinuxCon:
> > >
> > > > Bifurcated Driver: With the Bifurcated Driver, the kernel will
> > > > retain direct control of the NIC, and will assign specific queue pairs to
> DPDK.
> > > > Configuration of the NIC is controlled by the kernel via ethtool.
> > >
> > > This design allows to keep the configuration code in one place: the
> kernel.
> > > In the meantime, we are trying to add a lot of code to configure the
> > > NICs, which looks to be a duplication of effort.
> > > Why should we have two ways of configuring e.g. flow director?
> > >
> > > Since you at Intel, you'll be supporting your code, I am fine for
> > > duplication, but I feel it's worth arguing why both should be available
> instead of one.
> > >
> > > --
> > > Thomas

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] DPDK Features for Q1 2015
  2014-10-22 14:44   ` Zhou, Danny
@ 2014-10-22 15:05     ` Liang, Cunming
  0 siblings, 0 replies; 4+ messages in thread
From: Liang, Cunming @ 2014-10-22 15:05 UTC (permalink / raw)
  To: Zhou, Danny, Thomas Monjalon, O'driscoll, Tim
  Cc: dev, Fastabend, John R, Ronciak, John

> >
> > This design allows to keep the configuration code in one place: the kernel.
> > In the meantime, we are trying to add a lot of code to configure the NICs,
> > which looks to be a duplication of effort.
> > Why should we have two ways of configuring e.g. flow director?
[Liang, Cunming] The HW sometimes provides additional ability than existing abstraction API.
On that time(HW ability is a superset to the abstraction wrapper, e.g. flow director), we need to provide another choice.
Ethtools is good, but can't apply anything supported in NIC.
Bifurcated driver considers a lot on reusing existing rx/tx routine.
We'll send RFC patch soon if kernel patch moving fast.

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhou, Danny
> Sent: Wednesday, October 22, 2014 10:44 PM
> To: Thomas Monjalon; O'driscoll, Tim
> Cc: dev@dpdk.org; Fastabend, John R; Ronciak, John
> Subject: Re: [dpdk-dev] DPDK Features for Q1 2015
> 
> Thomas,
> 
> In terms of the bifurcated driver, it is actually the same thing. Specifically, the
> bifurcated
> driver PMD in DPDK depends on kernel code(af_packet and 10G/40G NIC)
> changes. Once the
> kernel patches are upstreamed, the corresponding DPDK PMDs patches will be
> submitted to dpdk.org. John Fastabend and John Ronciak are working with very
> closely to achieve the same goal.
> 
> -Danny
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Wednesday, October 22, 2014 10:21 PM
> > To: O'driscoll, Tim
> > Cc: dev@dpdk.org; Fastabend, John R; Ronciak, John
> > Subject: Re: [dpdk-dev] DPDK Features for Q1 2015
> >
> > Thanks Tim for sharing your plan.
> > It's really helpful to improve community collaboration.
> >
> > I'm sure it's going to generate some interesting discussions.
> > Please take care to discuss such announce on dev list only.
> > The announce@dpdk.org list is moderated to keep a low traffic.
> >
> > I would like to open discussion about a really important feature,
> > showed last week by John Fastabend and John Ronciak during LinuxCon:
> >
> > > Bifurcated Driver: With the Bifurcated Driver, the kernel will retain
> > > direct control of the NIC, and will assign specific queue pairs to DPDK.
> > > Configuration of the NIC is controlled by the kernel via ethtool.
> >
> > This design allows to keep the configuration code in one place: the kernel.
> > In the meantime, we are trying to add a lot of code to configure the NICs,
> > which looks to be a duplication of effort.
> > Why should we have two ways of configuring e.g. flow director?
> >
> > Since you at Intel, you'll be supporting your code, I am fine for duplication,
> > but I feel it's worth arguing why both should be available instead of one.
> >
> > --
> > Thomas

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] DPDK Features for Q1 2015
  2014-10-22 14:20 ` [dpdk-dev] " Thomas Monjalon
@ 2014-10-22 14:44   ` Zhou, Danny
  2014-10-22 15:05     ` Liang, Cunming
  0 siblings, 1 reply; 4+ messages in thread
From: Zhou, Danny @ 2014-10-22 14:44 UTC (permalink / raw)
  To: Thomas Monjalon, O'driscoll, Tim
  Cc: dev, Fastabend, John R, Ronciak, John

Thomas,

In terms of the bifurcated driver, it is actually the same thing. Specifically, the bifurcated 
driver PMD in DPDK depends on kernel code(af_packet and 10G/40G NIC) changes. Once the
kernel patches are upstreamed, the corresponding DPDK PMDs patches will be 
submitted to dpdk.org. John Fastabend and John Ronciak are working with very
closely to achieve the same goal.

-Danny

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, October 22, 2014 10:21 PM
> To: O'driscoll, Tim
> Cc: dev@dpdk.org; Fastabend, John R; Ronciak, John
> Subject: Re: [dpdk-dev] DPDK Features for Q1 2015
> 
> Thanks Tim for sharing your plan.
> It's really helpful to improve community collaboration.
> 
> I'm sure it's going to generate some interesting discussions.
> Please take care to discuss such announce on dev list only.
> The announce@dpdk.org list is moderated to keep a low traffic.
> 
> I would like to open discussion about a really important feature,
> showed last week by John Fastabend and John Ronciak during LinuxCon:
> 
> > Bifurcated Driver: With the Bifurcated Driver, the kernel will retain
> > direct control of the NIC, and will assign specific queue pairs to DPDK.
> > Configuration of the NIC is controlled by the kernel via ethtool.
> 
> This design allows to keep the configuration code in one place: the kernel.
> In the meantime, we are trying to add a lot of code to configure the NICs,
> which looks to be a duplication of effort.
> Why should we have two ways of configuring e.g. flow director?
> 
> Since you at Intel, you'll be supporting your code, I am fine for duplication,
> but I feel it's worth arguing why both should be available instead of one.
> 
> --
> Thomas

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] DPDK Features for Q1 2015
  2014-10-22 13:48 [dpdk-dev] [dpdk-announce] " O'driscoll, Tim
@ 2014-10-22 14:20 ` Thomas Monjalon
  2014-10-22 14:44   ` Zhou, Danny
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Monjalon @ 2014-10-22 14:20 UTC (permalink / raw)
  To: O'driscoll, Tim; +Cc: dev, john.r.fastabend, john.ronciak

Thanks Tim for sharing your plan.
It's really helpful to improve community collaboration.

I'm sure it's going to generate some interesting discussions.
Please take care to discuss such announce on dev list only.
The announce@dpdk.org list is moderated to keep a low traffic.

I would like to open discussion about a really important feature,
showed last week by John Fastabend and John Ronciak during LinuxCon:

> Bifurcated Driver: With the Bifurcated Driver, the kernel will retain
> direct control of the NIC, and will assign specific queue pairs to DPDK.
> Configuration of the NIC is controlled by the kernel via ethtool.

This design allows to keep the configuration code in one place: the kernel.
In the meantime, we are trying to add a lot of code to configure the NICs,
which looks to be a duplication of effort.
Why should we have two ways of configuring e.g. flow director?

Since you at Intel, you'll be supporting your code, I am fine for duplication,
but I feel it's worth arguing why both should be available instead of one.

-- 
Thomas

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-10-22 15:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-22 15:36 [dpdk-dev] DPDK Features for Q1 2015 Zhu, Heqing
  -- strict thread matches above, loose matches on Subject: below --
2014-10-22 13:48 [dpdk-dev] [dpdk-announce] " O'driscoll, Tim
2014-10-22 14:20 ` [dpdk-dev] " Thomas Monjalon
2014-10-22 14:44   ` Zhou, Danny
2014-10-22 15:05     ` Liang, Cunming

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).