[dpdk-dev] [dpdk-moving] Draft Project Charter

[O'Driscoll, Tim]

Agreed. I think we should use next week's meeting to walk through the document, 
discuss the comments, and agree on the changes.

As I said before, the two-level structure that's in there at the moment is a 
placeholder, but it does allow for one level of contribution to the shared lab 
and a lower level contribution for marketing purposes.


Tim

From: Matt Spencer [mailto:matt.spen...@arm.com]
Sent: Tuesday, November 8, 2016 6:18 PM
To: O'Driscoll, Tim ; Vincent JARDIN 
; moving at dpdk.org
Cc: dev at dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter


I think we need a discussion about the levels of membership - possibly at next 
weeks meeting?



My feeling is that we need more than one level

  - One to enable contribution of hardware to the lab, as the lab will add cost 
to the overall project budget

  - A second to enable contribution to the marketing aspects of the project and 
to allow association for marketing purposes



Calling these Gold and Silver is fine with me, but as I say, lets discuss this 
at next weeks meeting.



Matt


From: moving mailto:moving-bounces at dpdk.org>> on 
behalf of O'Driscoll, Tim mailto:tim.odrisc...@intel.com>>
Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving at dpdk.org<mailto:moving at dpdk.org>
Cc: dev at dpdk.org<mailto:dev at dpdk.org>
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving at dpdk.org<mailto:moving at dpdk.org>
> Cc: dev at dpdk.org<mailto:dev at dpdk.org>
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
>- you create the status of "Gold" members that we do not want from
> Linux Foundation,

As I said in the email, I put in two levels of membership as a placeholder. The 
first thing we need to decide is if we want to have a budget and membership, or 
if we want the OVS model with 0 budget and no membership. We can discuss that 
at today's meeting.

If we do want a membership model then we'll need to decide if everybody 
contributes at the same rate or if we support multiple levels. So, for now, the 
text on having two levels is just an example to show what a membership model 
might look like.

>- you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.

That's just standard text that I see in all the LF charters. It's even in the 
OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 
0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can 
clarify.

>
> Please, explain why you did change it?
>
> Thank you,
>Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[dpdk-dev] [dpdk-moving] Draft Project Charter

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving at dpdk.org
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
> 
> Tim,
> 
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
>- you create the status of "Gold" members that we do not want from
> Linux Foundation,

As I said in the email, I put in two levels of membership as a placeholder. The 
first thing we need to decide is if we want to have a budget and membership, or 
if we want the OVS model with 0 budget and no membership. We can discuss that 
at today's meeting.

If we do want a membership model then we'll need to decide if everybody 
contributes at the same rate or if we support multiple levels. So, for now, the 
text on having two levels is just an example to show what a membership model 
might look like.

>- you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.

That's just standard text that I see in all the LF charters. It's even in the 
OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 
0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can 
clarify.

> 
> Please, explain why you did change it?
> 
> Thank you,
>Vincent

[dpdk-dev] Project Governance and Linux Foundation

[O'Driscoll, Tim]

> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> 
> On Tue, Oct 18, 2016 at 03:27:27PM +0200, Thomas Monjalon wrote:
> > 2016-10-18 17:04, Jerin Jacob:
> > > On Mon, Oct 17, 2016 at 05:23:42PM -0400, Dave Neary wrote:
> > > > > I still hear concerns on this, and based on discussions with
> others who put their names to the post below, they do too. I think it's
> a perception that we need to address.
> > > >
> > > > I would say that there is still a perception issue, for companies
> who
> > > > look at the active developers, the owners of the project's
> resources
> > > > (infra, domain name), and who have heard anecdotal evidence of
> issues in
> > > > the past. I think the project has made a lot of progress since I
> have
> > > > been following it, and I do not believe there are any major issues
> with
> > > > the independence of the project. However, there are still
> concerned
> > > > parties on this front, and the concerns can be easily addressed by
> a
> > > > move to the LF.
> > >
> > > +1
> >
> > How can we solve issues if you don't give more details than
> > "hear concerns" or "heard anecdotal evidence of issues"?
> 
> Honestly, I don't see any issue in the current DPDK project execution.
> The concern was more towards the fact that multi-vendor infrastructure
> project
> like DPDK owned and controlled by the single company.
> 
> We believe, Moving to LF will fix that issue/perception and it will
> enable more users to use/consume/invest DPDK in their products.

+1. This is in danger of becoming a never-ending argument. We said in the 
original post that one of the goals of moving to LF is to "Remove any remaining 
perception that DPDK is not truly open". I believe that's an important goal for 
the project and one that we should all agree on.

Whether you choose the accept it or not, it's a fact that concerns exist in the 
community over the fact that one single company controls the infrastructure for 
the project. Moving the project to an independent body like the LF would fix 
that.

> Having said that, Does anyone see any issue in moving to LF?
> If yes, Then we should enumerate the issues and discuss further.

This is a great point. Can you explain what you see as the benefits of 
maintaining the current model? As far as I can see, the LF model provides 
everything that we currently have, plus it makes DPDK independent of any single 
company, and it also gives us the option of availing of other LF services if we 
choose to do so, including the ability to host lab infrastructure for the 
project, legal support for trademarks if we need that, event planning etc.

> 
> Jerin

[dpdk-dev] [dpdk-users] Project Governance and Linux Foundation

[O'Driscoll, Tim]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, October 17, 2016 1:41 PM
> To: users at dpdk.org; dev at dpdk.org
> Cc: O'Driscoll, Tim ; Hobywan Kenoby
> 
> Subject: Re: [dpdk-users] Project Governance and Linux Foundation
> 
> 2016-10-17 11:52, O'Driscoll, Tim:
> > From: Hobywan Kenoby
> > > The current DPDK version can run on virtually all processors (Intel,
> IBM
> > > and ARM) and leverage all NICs: is there **really** anyone
> questionning
> > > openness of the community?
> >
> > I still hear concerns on this, and based on discussions with others
> who
> > put their names to the post below, they do too.
> > I think it's a perception that we need to address.
> 
> It is simple to address this perception with fact checking.
> The next releases will provide even more code for ARM and NPUs.
> If someone submits some good code and is ignored, it is easy enough
> to ping the mailing list and make it visible.
> If someone sees any regression on his architecture, we care.
> Please let's stop maintaining confusion on this topic.
> 
> DPDK *is* truly open.

Well, to be a little more specific, the concern I've heard on many occasions is 
that 6WIND control the infrastructure for the project and so effectively have a 
veto over what's accepted into DPDK. Your argument is that you've never 
exercised that veto, which is true, but you still have the ability to do so. 
That's not a characteristic of a truly open project. As stated in the original 
post on this:

> - The infrastructure for a project like DPDK should not be owned and 
> controlled by any single company.

[dpdk-dev] Project Governance and Linux Foundation

[O'Driscoll, Tim]

Hi HK,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hobywan Kenoby
> Sent: Monday, October 17, 2016 11:24 AM
> To: O'Driscoll, Tim ; dev at dpdk.org;
> users at dpdk.org
> Subject: Re: [dpdk-dev] Project Governance and Linux Foundation
> 
> Hi Tim,
> 
> 
> The Linux kernel community has a governance close to DPDK. It did allow
> companies to grow largebusinesses and indivuals to take an
> active and even influencial roles based on their technical expertise and
> merits.
> 
> I don't really understand what can be gained by moving to Linux
> Foundation, but I am almost sure that no individual expert will be able
> to take any leaderhip role as those roles will be fulfilled by Platinum,
> Gold or Silver members: right ?

No. If DPDK were to move to LF as an independent project, then as discussed at 
the Userspace event in Dublin last year, and as documented in the original post 
below, the intention would be not to make any significant changes to the 
technical governance.

If DPDK were to move to FD.io the situation would be the same. The FD.io 
Technical Community Charter 
(https://fd.io/governance/technical-community-charter) specifies how Project 
Technical Leaders and Committers are nominated and approved, but there's no 
requirement for people in those roles to come from Platinum, Gold or Silver 
FD.io members. Those decisions are based purely on technical merit.

> VPP is a virtual switch that has its own event model that may compete
> with the new model proposed by Intel, Cavium and NXP. What would be the
> acceptability of such a proposal if DPDK would have been folded into
> FD.IO?

Acceptance of the libeventdev proposal would be no different if DPDK were part 
of FD.io. It would be reviewed and accepted based on its technical merit.

FD.io is an umbrella project comprising a number of individual sub-projects. 
Those sub-projects are free to make their own technical decisions. This is 
documented in the Guiding Principles section of the FD.io Technical Community 
Charter (https://fd.io/governance/technical-community-charter):

4.Technical decisions (including release decisions) for a project should be 
made by consensus of that project's Committers.  If consensus cannot be 
reached, decisions are made by a majority vote of a project's Committers.  
Committers on a project may, by majority vote, delegate (or revoke delegation 
of) any portion of the project's decisions to an alternate open, documented, 
traceable decision making process.

> Intellectual property is probably properly handled in this community (I
> don't really know a lot about this): are there things to be done on DPDK
> to match was proved to be sufficient in Linux kernel?

I think Intellectual Property is already properly handled within DPDK. Being 
part of the Linux Foundation would provide a legal framework for dealing with 
any trademark or other legal issues that may occur in future.

> The current DPDK version can run on virtually all processors (Intel, IBM
> and ARM) and leverage all NICs: is there **really** anyone questionning
> openness of the community?

I still hear concerns on this, and based on discussions with others who put 
their names to the post below, they do too. I think it's a perception that we 
need to address.

> 
> - HK
> 
> 
> 
> 
> From: dev  on behalf of O'Driscoll, Tim
> 
> Sent: Monday, October 10, 2016 10:33 AM
> To: dev at dpdk.org; users at dpdk.org
> Subject: [dpdk-dev] Project Governance and Linux Foundation
> 
> This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red
> Hat.
> 
> 
> Since its creation as an open source project in 2013, DPDK has grown
> significantly. The number of DPDK users, contributors, commercial
> products that use DPDK and open source projects that depend on it have
> all increased consistently over that time. DPDK is now a key ingredient
> in networking and NFV, and we need to ensure that the project structure
> and governance are appropriate for such a critical project, and that
> they facilitate the project's continued growth.
> 
> For over a year now we've been discussing moving DPDK to the Linux
> Foundation. We believe it's now time to conclude that discussion and
> make the move. The benefits of doing this would include:
> - The infrastructure for a project like DPDK should not be owned and
> controlled by any single company.
> - Remove any remaining perception that DPDK is not truly open.
> - Allow the project to avail of the infrastructure and services provided
> by the Linux Foundation. These include things like: Ability to host
> infrastructure for integration and testing (the FD.io CSIT lab is an
> example of this - see https://wiki.fd.io/view/CSIT/CSIT_LF_testbed);
> Support for le

[dpdk-dev] 17.02 Roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, October 14, 2016 9:19 PM
> To: Stephen Hemminger 
> Cc: dev at dpdk.org; O'Driscoll, Tim 
> Subject: Re: [dpdk-dev] 17.02 Roadmap
> 
> 2016-10-14 10:29, Stephen Hemminger:
> > It seems like a lot of these feature are focused too narrowly on
> exposing
> > features that exist on specific Intel hardware. The concept of a
> general
> > purpose Dataplane Development Kit is that applications can be written
> that
> > have a generic API (like any operating system) that will run on a wide
> > variety of hardware.  This concept seems to getting lost as the DPDK
> is
> > becoming more of a platform for exposing what ever cool hardware
> features
> > exist.
> >
> > I would propose that no new feature be allowed in the DPDK unless it
> > can be supported on all device types. Yes that means you have to build
> > and test software emulation layers for all other devices. The current
> > model is more of a hardware test bed.
> 
> Thanks for the reminder Stephen. It is good goal.
> I think the software emulation idea is finding its way.
> About forbidding new hardware feature without emulation support,
> it has to be discussed.

We have a roadmap discussion on Thursday morning at the Userspace event in
Dublin. The aim is to discuss any gaps in the roadmap and see what can be 
done to address them. I think this would be a great topic to discuss then.

[dpdk-dev] 17.02 Roadmap

[O'Driscoll, Tim]

> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> 
> Thanks Tim for the interesting inputs.
> Some of them may require a dedicated thread to continue the discussion
> based on some preliminary specifications or drafts.

Agreed. To avoid me acting as a middle man, I'm going to ask the individual 
developers to respond initially to this thread. If more discussion is required 
on some of the items, then we should create separate threads.

[dpdk-dev] 17.02 Roadmap

[O'Driscoll, Tim]

We published our initial roadmap for 17.02 at the end of August. Since then 
we've been doing more detailed planning and would like to provide an update on 
the features that we plan to submit for this release. This is our current plan, 
which should hopefully remain fairly stable now:

Consistent Filter API: Add support for the Consistent Filter API (see 
http://dpdk.org/ml/archives/dev/2016-September/047924.html) for IGB, IXGBE and 
I40E.

Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-based 
load balancing library which scales linearly for both lookup and insert with 
the number of threads or cores.  EFD lookup uses a "perfect hashing" scheme 
where only the information needed to compute a key's value (and not the key 
itself) is stored in the lookup table, thus reducing CPU cache storage 
requirements. 

Extended Stats (Latency and Bit Rate Statistics): Enhance the Extended NIC 
Stats (Xstats) implementation to support the collection and reporting of 
latency and bit rate measurements. Latency statistics will include min, max and 
average latency, and jitter. Bit rate statistics will include peak and average 
bit rate aggregated over a user-defined time period. This will be implemented 
for IXGBE and I40E.

Run-Time Configuration of Packet Type (PTYPE) for I40E: At the moment all 
packet types in DPDK are statically defined. This makes impossible to add new 
values without first defining them statically and then recompiling DPDK. The 
ability to configure packet types at run time will be added for I40E.

Packet Distributor Enhancements: Enhancements will be made to the Packet 
Distributor library to improve performance:
1. Introduce burst functionality to allow batches of packets to be sent to 
workers.
2. Improve the performance of the flow/core affinity through the use of SSE/AVX 
instructions.

Add MACsec for IXGBE: MACsec support will be added for IXGBE. Ethdev API 
primitives will be added to create/delete/enable/disable SC/SA, Next_PN etc. 
similar to those used in Linux for the macsec_ops. Sample apps (l3fwd, testpmd, 
etc.) will be updated to support MACsec for the IXGBE. 

Enhance AESNI_GCM PMD: The current AESNI_GCM PMD is limited to AES-128 and does 
not support other features such as "any AAD length value". It will be updated 
to use a newer GCM implementation supporting AES128/192/256 and other features.

Create Crypto Performance Test App: A new app, similar to testpmd, will be 
created to allow crypto performance to be tested using any crypto PMD and any 
supported crypto algorithm.

Enable Cipher-Only and Hash-Only Support in AESNI_MB PMD: Support will be added 
for cipher-only and hash-only operations in the AESNI_MB PMD.

Support Chained Mbufs in Cryptodev: Currently, an application using the 
cryptodev API needs to reserve a continuous block of memory for mbufs. Support 
will be added for chaining of mbufs in both the QAT and SW PMDs supported by 
cryptodev.

Optimize Vhost-User Performance for Large Packets: A new memory copy function 
optimized for core-to-core memory copy which will be added. This will be 
beneficial for virtualization cases involving large packets, but it can be used 
for other core-to-core cases as well.

Support New Device Types in Vhost-User: Support will be added to vhost-user for 
new device types including vhost-scsi and vhost-blk.

Interrupt Mode Support in Virtio PMD: Support for interrupt mode will be added 
to the virtio PMD.

Virtio-User as an Alternative Exception Path: Investigate the use of 
virtio-user and vhost-net as an alternative exception path to KNI that does not 
require out of tree drivers. This work is still at an experimental stage, so it 
may not be included in 17.02.


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Wednesday, August 31, 2016 11:32 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] 17.02 Roadmap
> 
> Below are the features that we're planning to submit for the 17.02
> release. We'll submit a patch to update the roadmap page with this info.
> 
> Some things will obviously change during planning/development, so we'll
> provide a more detailed update in late September/early October. After
> that, things should hopefully be relatively stable.
> 
> It would be good if others are also willing to share their plans so that
> we can build up a complete picture of what's planned for 17.02 and make
> sure there's no duplication.
> 
> 
> Consistent Filter API phase 2: Extend support for the Consistent Filter
> API that will be first implemented in 16.11 to IGB and FM10K.
> 
> Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-
> based load balancing library which scales linearly for both lookup and
> insert with the number of threads or cores.  EFD lookup uses a "perfect
> hashing" scheme where only the information needed to 

[dpdk-dev] Project Governance and Linux Foundation

[O'Driscoll, Tim]

This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red Hat.


Since its creation as an open source project in 2013, DPDK has grown 
significantly. The number of DPDK users, contributors, commercial products that 
use DPDK and open source projects that depend on it have all increased 
consistently over that time. DPDK is now a key ingredient in networking and 
NFV, and we need to ensure that the project structure and governance are 
appropriate for such a critical project, and that they facilitate the project's 
continued growth.

For over a year now we've been discussing moving DPDK to the Linux Foundation. 
We believe it's now time to conclude that discussion and make the move. The 
benefits of doing this would include:
- The infrastructure for a project like DPDK should not be owned and controlled 
by any single company.
- Remove any remaining perception that DPDK is not truly open.
- Allow the project to avail of the infrastructure and services provided by the 
Linux Foundation. These include things like: Ability to host infrastructure for 
integration and testing (the FD.io CSIT lab is an example of this - see 
https://wiki.fd.io/view/CSIT/CSIT_LF_testbed); Support for legal issues 
including trademarks and branding, and the ability to sign agreements on behalf 
of the project; Ability to pool resources for events and brand promotion; Safe 
haven for community IP resources.

We don't propose to debate the details here. Instead, an open discussion 
session on DPDK Project Growth has been included in the agenda for the DPDK 
Summit Userspace 2016 event in Dublin. We propose using that session to agree 
that the DPDK project will move to the Linux Foundation, and then to move on to 
discussing the specifics. Things that we'll need to consider include:
- Whether DPDK moves to the Linux Foundation as an independent project or as 
part of a larger project like FD.io.
- Creation of a project charter similar to those created for FD.io 
(https://fd.io/governance/technical-community-charter) and Open vSwitch (see 
http://openvswitch.org/pipermail/discuss/attachments/20160619/5a2df53e/attachment-0001.pdf).
- Agreement on budget, membership levels etc. A draft budget was created by the 
LF during previous discussions 
(https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256),
 but it is possible to adopt an even more lightweight model.

We could look at alternatives to the Linux Foundation, but a) we've been 
talking to the LF for over a year now, and b) the preponderance of networking 
projects in LF, like ODL, FD.io, and OVS, makes it a natural destination for 
DPDK.

As highlighted in previous discussions on this topic, it's important to stress 
that the intent is not to make significant changes to the technical governance 
and decision making of the project. The project has a strong set of maintainers 
and a Technical Board in place already. What's required is to supplement that 
with an open governance structure taking advantage of the services offered by 
the Linux Foundation.

The purpose of this email is to outline what we want to achieve during that 
discussion session in Dublin, and to allow people to consider the issue and 
prepare in advance. If people want to comment via email on the mailing list, 
that's obviously fine, but we believe that an open and frank discussion when 
people meet in person in Dublin is the best way to progress this.


For reference, below is a brief history of the previous discussions on this 
topic:

September 2015:
- A DPDK community call was held to discuss project growth and possible 
improvements. This was the first public discussion on possible governance 
changes. The agreed next step was to discuss this in more detail at the 2015 
DPDK Summit Userspace event Dublin. Minutes of the call are at: 
http://dpdk.org/ml/archives/dev/2015-September/024120.html.

October 2015:
- An open discussion session on project governance was held at the 2015 DPDK 
Summit Userspace event. For technical governance, we agreed to investigate 
creating a technical steering committee. For non-technical governance 
(including things like event planning, legal and trademark issues, hosting of 
the website etc.), we agreed to work with the Linux Foundation on a proposal 
for a lightweight governance model for DPDK. Minutes of the discussion are at: 
http://dpdk.org/ml/archives/dev/2015-October/024825.html.

- The proposal for a technical steering committee was subsequently discussed on 
the mailing list (http://dpdk.org/ml/archives/dev/2015-October/026598.html) and 
agreed, leading to the creation of the DPDK Technical Board 
(http://dpdk.org/dev#board).

December 2015:
- A community call was held to discuss migration to the Linux Foundation. Mike 
Dolan (VP of Strategic Programs at The Linux Foundation) gave an overview of 
the LF and the services they can provide. We agreed to form a small sub-team 
(Dave Neary, Thomas Monjalon, 

[dpdk-dev] 17.02 Roadmap

[O'Driscoll, Tim]

Below are the features that we're planning to submit for the 17.02 release. 
We'll submit a patch to update the roadmap page with this info.

Some things will obviously change during planning/development, so we'll provide 
a more detailed update in late September/early October. After that, things 
should hopefully be relatively stable.

It would be good if others are also willing to share their plans so that we can 
build up a complete picture of what's planned for 17.02 and make sure there's 
no duplication.


Consistent Filter API phase 2: Extend support for the Consistent Filter API 
that will be first implemented in 16.11 to IGB and FM10K.

Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-based 
load balancing library which scales linearly for both lookup and insert with 
the number of threads or cores.  EFD lookup uses a "perfect hashing" scheme 
where only the information needed to compute a key's value (and not the key 
itself) is stored in the lookup table, thus reducing CPU cache storage 
requirements.

Cryptodev: Additional Software Algorithms: 
- Optimize the AES-GCM software PMD.
- Enhance the Intel(r) AES-NI MB PMD to add support for cipher-only and 
authentication-only operations. Add support for AES_CBC_MAC, AES_CMAC_128, 
AES_GMAC_128.
- Add software support for: 3DES_ECB_128/192, AES_ECB_128/192/256, AES_F8, 
AES_XTS, ARC4.

Run-Time Configuration of Flow Type (PCTYPE) and Packet Type (PTYPE) for I40E: 
At the moment all flow types and packet types in DPDK are statically defined. 
This makes impossible to add new values without first defining them statically 
and then recompiling DPDK. The ability to configure flow types and packet types 
at run time will be added for I40E.

Extended Stats Latency and Bit Rate Statistics: Enhance the Extended NIC Stats 
(Xstats) implementation to support the collection and reporting of latency and 
bit rate measurements. Latency statistics will include min, max and average 
latency, and jitter. Bit rate statistics will include peak and average bit rate 
aggregated over a user-defined time period. This will be implemented for IXGBE 
and I40E.

Hardware QoS for IXGBE and I40E: Implement support for Hardware QoS for IXGBE 
and I40E. This involves using DCB so that a PF or VF can receive packets for 
each of the Traffic Classes (TCs) based on the User Priority field (in the VLAN 
header). Bandwidth on transmit for each TC is programmable.

[dpdk-dev] 16.11 Roadmap

[O'Driscoll, Tim]

We published our initial roadmap for 16.11 at the start of May. Since then, 
we've been doing more detailed planning and would like to provide an update on 
the features that we plan to submit for this release.

We'll schedule a community call where some of our software developers will 
describe their work in a bit more detail and answer any questions. It would be 
good if others are also willing to share their plans so that we can build up a 
complete picture of what's planned for 16.11.

This is what we're planning to submit for 16.11:

Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist 
Technology) for Additional Algorithms:
Add support for additional algorithms which are supported by Intel(r) 
QuickAssist Technology but are not currently supported in DPDK. This includes: 
3DES_CBC_128/192, KASUMI, NULL, SHA224_HMAC, SHA384_HMAC and AES-GMAC. 

Cryptodev Support for Software Acceleration for Additional Algorithms:
Add support for software implementations of additional crypto algorithms. This 
includes: ZUC (EEA3 and EIA3) and 3DES_CBC_128/192 with MD5_HMAC, 
SHA1/SHA224/SHA256_HMAC and AES-GMAC.  ZUC will be supported via an optimized 
software library similar to KASUMI and SNOW3G. 3DES, and potentially other 
software implementations in future, will not be an optimized implementation, so 
it will not perform to the same level as other optimized software libraries.

Cryptodev Performance Optimization:
Analyze the performance of the cryptodev API, identify bottlenecks, and 
optimize where required.

IPsec Sample App Enhancements:
Add support for AES-GCM, AES-CTR, config file support to remove hard-coding of 
SAs/SPs etc., use forward cipher function to generate IV on CBC mode.

Generic Flow Director/Filtering/Classification API:
When a Generic Flow Director/Filtering/Classification API is agreed (see 
Adrien's RFC: http://dpdk.org/ml/archives/dev/2016-July/043365.html), implement 
support for that API for ixgbe and i40e.

Cuckoo Hash Enhancements:
Optimize the Cuckoo Hash lookup stages by using intelligent prefetching for 
keys and using IA AVX instructions for vector processing of keys.

Add vHost PMD xStats:
Update the vHost PMD to support the extended statistics API.

Delay Packet Copy in vHost-User Dequeue:
It may be possible to increase vhost-user performance by delaying the packet 
copy on Tx until a point where we know for certain whether the copy is required 
or not. This would avoid copying the packet in cases where it is not definitely 
required. Further investigation is required to determine how much of a 
performance gain can be achieved.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Tuesday, May 3, 2016 12:25 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] 16.11 Roadmap
> 
> We were a little late doing this for 16.07, so we're going to try and
> communicate our roadmap for future releases earlier. Our aim is to do
> this 6 months before a release. Some things will obviously change during
> planning/development, so we'll provide an update 4 months before the
> release. After that, things should hopefully be relatively stable.
> 
> Below are the features that we're planning to submit for 16.11. It would
> be good if others are also willing to share their plans so that we can
> build up a complete picture of what's planned for 16.11.
> 
> 
> Cryptodev Scheduler & Packet Reordering:
> Add a scheduler to cryptodev which will allow hardware and software
> acceleration to be used on the same core. If both are available, the
> scheduler will determine whether to use hardware or software
> acceleration based on packet size and other factors (TBD). Support
> packet reordering in cryptodev so that packet order is maintained when
> hardware and software acceleration are combined.
> 
> Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist
> Technology) for Additional Algorithms:
> Add support for all algorithms which are supported by Intel(r)
> QuickAssist Technology but are not currently supported in DPDK. This
> includes: AES_CTR_128/192/256, MD5, MD5_HMAC, SHA1, SHA224, SHA224_HMAC,
> SHA256, SHA384, SHA384_HMAC, SHA512, AES-XTS, KASUMI.
> 
> Cryptodev Support for Software Acceleration for Additional Algorithms:
> For every algorithm that we support in hardware, provide a software
> implementation. This means that an application can always rely on the
> cryptodev API to provide the requested service, even if hardware
> acceleration is not available.
> 
> Cryptodev Performance Optimization:
> Analyze the performance of the cryptodev API, identify bottlenecks, and
> optimize where required.
> 
> Generic Classification API:
> Create a new API to provide generic filtering capabilities that works
> across NICs. This will include a software implementation which can

[dpdk-dev] DPDK Summit USA 2016, Announcement and Call for Speakers

[O'Driscoll, Tim]

We're delighted to announce that the DPDK Summit USA 2016 will be held on 
August 10th & 11th at The Tech Museum of Innovation (http://www.thetech.org), 
San Jose.

The DPDK Summit events provide an opportunity for the DPDK community to meet 
face-to-face and discuss the future direction of the project in a variety of 
industry segments including telco, cloud, enterprise, security, and financial 
services. The agenda will cover the latest developments to the DPDK framework, 
plans for future releases, as well as an opportunity to hear from DPDK users 
who have used the framework in their applications. The Summits also provide a 
great opportunity to meet and learn from other DPDK developers.

This year, we've extended our USA Summit to 2 days, so that we can accommodate 
additional technical presentations and discussions. The full agenda is 
currently being determined and will be published in advance of the Summit.

Please join us to hear the latest developments in DPDK, and to help shape the 
future direction of packet processing.

You can register for this event at: http://dpdksummit.com.

We're also initiating a Call for Speakers for this event. To submit a proposal 
for a full presentation or a lightning talk on any DPDK-related topic, please 
email dpdk.summit at intel.com by Friday June 24th, providing the following 
details:
- Presentation or lightning talk
- Title
- Abstract
- Presenter name, company, title, contact details


Registration Policies: Cancellations, Substitutions & Changes
- If  you need to cancel your DPDK Summit USA 2016 registration, you may do so 
until August 3rd,  2016. If you are unable to attend the event, we recommend 
that you send a substitute in your place.  Please send your cancelation or 
substitution name changes to dpdk.summit at intel.com.
- DPDK Summit USA 2016 reserves the right to rescind any registration. All 
dates and times of DPDK Summit USA 2016 are subject to change.
- If  you have a disability and require special assistance, please contact 
dpdk.summit at intel.com.
- Attendee consents to any recording of the event by Intel or its designees.

[dpdk-dev] 16.11 Roadmap

[O'Driscoll, Tim]

We were a little late doing this for 16.07, so we're going to try and 
communicate our roadmap for future releases earlier. Our aim is to do this 6 
months before a release. Some things will obviously change during 
planning/development, so we'll provide an update 4 months before the release. 
After that, things should hopefully be relatively stable.

Below are the features that we're planning to submit for 16.11. It would be 
good if others are also willing to share their plans so that we can build up a 
complete picture of what's planned for 16.11.


Cryptodev Scheduler & Packet Reordering:
Add a scheduler to cryptodev which will allow hardware and software 
acceleration to be used on the same core. If both are available, the scheduler 
will determine whether to use hardware or software acceleration based on packet 
size and other factors (TBD). Support packet reordering in cryptodev so that 
packet order is maintained when hardware and software acceleration are combined.

Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist 
Technology) for Additional Algorithms:
Add support for all algorithms which are supported by Intel(r) QuickAssist 
Technology but are not currently supported in DPDK. This includes: 
AES_CTR_128/192/256, MD5, MD5_HMAC, SHA1, SHA224, SHA224_HMAC, SHA256, SHA384, 
SHA384_HMAC, SHA512, AES-XTS, KASUMI.

Cryptodev Support for Software Acceleration for Additional Algorithms:
For every algorithm that we support in hardware, provide a software 
implementation. This means that an application can always rely on the cryptodev 
API to provide the requested service, even if hardware acceleration is not 
available.

Cryptodev Performance Optimization:
Analyze the performance of the cryptodev API, identify bottlenecks, and 
optimize where required.

Generic Classification API:
Create a new API to provide generic filtering capabilities that works across 
NICs. This will include a software implementation which can be used in cases 
where NICs that don't support all the capabilities of the API. An RFC will be 
submitted in the 16.07 timeframe. We're targeting the implementation at the 
16.11 release, but this is a complex change and there may be significant 
community interest/feedback on it, so it may be deferred until a later release.

Enhanced Packet Distributor:
Optimize performance of the Packet Distributor library by using vector 
instructions and other techniques.

QEMU vHost Back-End Reconnect:
Currently, if a vswitch is connected to VMs via vhost-user and the vswitch is 
restarted, then when it comes back up again it cannot reconnect to the existing 
VMs. To address this, both QEMU and vhost-user need to support client mode 
(currently only server mode is supported), which implements reconnection 
messages that allow the vswitch to reconnect to the VMs. Changes are required 
in QEMU as well as in DPDK, so this change will need to be coordinated with the 
QEMU community.

Delay Packet Copy in vHost-User Dequeue:
It may be possible to increase vhost-user performance by delaying the packet 
copy until a point where we know for certain whether the copy is required or 
not. This would avoid copying the packet in cases where it is not definitely 
required. Further investigation is required to determine how much of a 
performance gain can be achieved.

Cuckoo Hash Acceleration using TSX:
Improve performance of Cuckoo Hash using Transactional Synchronization 
Extensions (TSX).

[dpdk-dev] DPDK Community Call - 16.04 Retrospective - Wednesday May 11th

[O'Driscoll, Tim]

At the end of each release, we typically hold a retrospective within our 
development team to discuss what went well, what could be improved etc. For 
16.04, we thought it would be a good idea to try doing this with the open 
source community, so that everybody involved in the project can provide their 
input and we can discuss any suggested improvements collectively.

Mike Glynn, who's our Program Manager for DPDK, will facilitate the discussion. 
John McNamara has gathered some stats on things like how many revisions patches 
typically went through etc., which we'll present to help initiate the 
discussion, but the meeting should mostly be an open discussion where people 
should feel free to suggest any improvements they think we should make.

If the approach is successful we can repeat it for future releases.


When:
London (United Kingdom - England)Wednesday, May 11, 2016 at 4PMBST  
UTC+1 hour 
San Jose (USA - California)  Wednesday, May 11, 2016 at 8AMPDT  
UTC-7 hours
Boston (USA - Massachusetts) Wednesday, May 11, 2016 at 11AM   EDT  
UTC-4 hours
Paris (France - ?le-de-France)   Wednesday, May 11, 2016 at 5PMCEST 
UTC+2 hours
New Delhi (India - Delhi)Wednesday, May 11, 2016 at 8:30PM IST  
UTC+5:30 hours 
Shanghai (China - Shanghai Municipality) Wednesday, May 11, 2016 at 11PM   CST  
UTC+8 hours
Tokyo (Japan)Midnight between Wednesday, May 11 and 
Thursday, May 12 JST  UTC+9 hours


GoToMeeting details:
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/634498213

You can also dial in using your phone. 
United States : +1 (312) 757-3117

Access Code: 634-498-213

More phone numbers
Australia : +61 2 8355 1039
Austria : +43 7 2088 1033
Belgium : +32 (0) 28 93 7001
Canada : +1 (647) 497-9379
Denmark : +45 69 91 89 33
Finland : +358 (0) 942 41 5770
France : +33 (0) 170 950 585
Germany : +49 (0) 692 5736 7303
Ireland : +353 (0) 19 030 050
Italy : +39 0 693 38 75 50
Netherlands : +31 (0) 208 080 208
New Zealand : +64 9 925 0481
Norway : +47 21 54 82 21
Spain : +34 911 82 9890
Sweden : +46 (0) 853 527 817
Switzerland : +41 (0) 435 0167 65
United Kingdom : +44 (0) 330 221 0099

[dpdk-dev] 16.07 Roadmap

[O'Driscoll, Tim]

As we're nearing the completion of the 16.04 release, I'd like to let the 
community know our plans for 16.07. It would be good if others are also willing 
to share their plans so that we can build up a complete picture of what's 
targeted for 16.07.

These are the features that we're planning to submit:

Vhost/Virtio Performance Loopback Utility: A tool will be provided which will 
allow virtio/vhost performance testing without the need for NIC traffic.

Virtio Code Refactoring for Rx/TX Split: The Rx and Tx queues will be split as 
they have different information to maintain apart from the common vring. Other 
cleanups will be made to make the queues more friendly for optimization.

Virtio Descriptor Index Update: The virtio descriptor index will be optimized 
for cache2cache transfer in the virtio PMD. The performance increase is 
expected to be below 10%.

Virtio in Containers: Support will be added for virtio in containers (see 
http://dpdk.org/ml/archives/dev/2016-February/032786.html). Multi-queue support 
will also be added.

I40e NSH: This includes: 1. Recognize the Network Services Header packet type; 
2. Direct traffic to queues based on service path header and service index 
(dependent on firmware change so may not make 16.07); 3. Checksum offload.

I40e Floating VEB: Deferred from 16.04. See 
http://dpdk.org/ml/archives/dev/2016-March/036470.html for details.

Automatic VF Reset From PF (i40e/ixgbe): Currently, when a PF notifies a VF 
that a reset is required, DPDK just reports this event to the application, 
which then needs to restart the VF port. A more user-friendly mechanism will be 
implemented where DPDK will reset the VF port directly. The application will 
still be notified, but will not need to handle the reset of the VF port.

Software Implementation of the KASUMI Algorithm: Under the cryptodev API, a 
software implementation of the KASUMI algorithm will be supported. KASUMI is 
widely used in mobile communications systems.

Bit-Level Support for SNOW 3G: Support for the SNOW 3G algorithm is being added 
in the 16.04 release. In 16.07, this will be enhanced so that offsets and 
lengths can be specified in bits instead of bytes (so, you could encrypt 50 
bits of a stream starting from the 5th bit for example).

IPsec Sample App Enhancements: Support for IPv6 and Transport Mode will be 
added to the IPsec sample application that was submitted in 16.04.

XStats Enhancements: Improve the extended NIC stats API to use id value pairs 
instead of string value pairs. Remap stats registers to use standard interface 
MIB naming and sizing.

Keep-Alive Enhancements: Improve DPDK keep-alive to use the DPDK 
alarm/interrupt API instead of using callbacks.

Live Migration for SRIOV: Support for live migration for vhost-user is being 
added to 16.04. This will be further enhanced to support live migration for 
SR-IOV by using link bonding to bond an SRIOV interface with a virtio interface.

IP Pipeline Enhancements: This includes: 1. Configure the MAC address in the 
routing pipeline; 2. Enable RSS per network interface through the configuration 
file; 3. Streamline the CLI code of the IP pipeline application.

Packet Capture Framework: In 16.04, there was lots of discussion on 
requirements for tcpdump support in DPDK (see 
http://dpdk.org/ml/archives/dev/2016-March/035592.html). For 16.07, we plan to 
submit a packet capture framework which will support hooks for filtering 
capabilities such as BPF. Our specific use case for this is for low rate packet 
capture for debug purposes. It should be possible for others to extend the 
framework to support high rate packet capture if they require that capability.

External Mempool Manager: This was originally submitted for 16.04 but had to be 
deferred due to ABI changes. See 
http://dpdk.org/ml/archives/dev/2016-March/035107.html for details.


In addition, there are some features that we're working on now but which we 
know won't make 16.07, either because time is too tight or because of external 
dependencies. These include:

QEMU vHost Back-End Reconnect: Currently, if a vswitch is connected to VMs via 
vhost-user and the vswitch is restarted, then when it comes back up again it 
cannot reconnect to the existing VMs. To address this, both QEMU and vhost-user 
need to support client mode (currently only server mode is supported), which 
implements reconnection messages that allow the vswitch to reconnect to the 
VMs. Changes are required in QEMU as well as in DPDK, so this change will need 
to be coordinated with the QEMU community.

Delay Packet Copy in vHost-User Dequeue: It may be possible to increase 
vhost-user performance by delaying the packet copy until a point where we know 
for certain whether the copy is required or not. This would avoid copying the 
packet in cases where it is not definitely required. Further investigation is 
required to determine how much of a performance gain can be achieved.


Tim

[dpdk-dev] [dpdk-announce] DPDK Summit China/Asia-Pacific 2016

[O'Driscoll, Tim]

We're delighted to announce that the first event in our DPDK Summit series for 
2016, for the China/Asia-Pacific region, will be held on Wednesday May 18th at 
the Renaissance Shanghai Yangtze Hotel, Shanghai, China.

The DPDK community in the China/Asia-Pacific region will meet face-to-face at 
this event and continue a dialogue on the future direction of packet processing 
in a variety of industry segments?including telecom, cloud, enterprise, 
security, financial services, and healthcare. A multitude of technical 
issues?facing the DPDK community will be discussed, with opportunities to learn 
from peers, DPDK architects and developers. This event provides a platform for 
personal networking in the DPDK community making us a productive, cohesive, and 
lively open source community!

Presentations at the event will be delivered mostly in Mandarin, but real-time 
translation into English will be available.

You can register for the event at: https://dpdksummit.com/us/en/registration

To submit an abstract for a presentation at this event, please 
contact?dpdk-china-event at intel.com.


Details of further events in the 2016 DPDK Summit series will follow later, but 
current plans include:

DPDK Summit USA: As discussed at one of our recent community calls, our aim is 
to hold this some time over the summer in the Bay Area. We're working with the 
Linux Foundation event planning team to identify possible dates and locations.

DPDK Userspace: Following the success of last year's event, we'll be holding 
this again in Dublin in October, probably on Oct 20th-21st. 

[dpdk-dev] [dpdk-announce] call to join Linux Foundation

[O'Driscoll, Tim]

> -Original Message-
> From: announce [mailto:announce-bounces at dpdk.org] On Behalf Of Thomas
> Monjalon
> Sent: Monday, February 15, 2016 3:15 PM
> To: announce at dpdk.org
> Subject: [dpdk-announce] call to join Linux Foundation
> 
> After few meetings and emails, it has been agreed to work with
> the Linux Foundation to assist the growing community of the DPDK. 
> 
> The outlines and the budget are described in this email by Tim
> O'Driscoll:
>   http://dpdk.org/ml/archives/dev/2016-February/032720.html
> 
> We need around ten companies to contribute to this small effort and
> become a supporter of the initiative.
> 
> As suggested by Dave Neary, the next step is to draft a membership
> agreement and identify the members of this new lightweight foundation:
>   http://dpdk.org/ml/archives/dev/2016-February/032909.html
> 
> Please, it would be great to use this thread to announce the official
> commitment of your company to support the DPDK community!

Thanks Thomas for progressing this. Intel will support moving the DPDK 
community to the Linux Foundation as we believe this will be in the best 
long-term interests of the project.


Tim

[dpdk-dev] DPDK Community Call - Linux Foundation

[O'Driscoll, Tim]

> -Original Message-
> From: Bob Monkman [mailto:Bob.Monkman at arm.com]
> Sent: Friday, February 5, 2016 4:30 PM
> To: O'Driscoll, Tim; dev at dpdk.org; Laura Kempke; Michael Dolan
> Subject: RE: DPDK Community Call - Linux Foundation
> 
> Thanks very much for the minutes. Can we get Laura's draft deck re:
> budget and tradeoffs/options?

There's no slide deck, just the spreadsheet at: 
https://docs.google.com/a/linuxfoundation.org/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit?usp=sharing.
 This outlines the minimum (column B) and optional (column C) alternatives that 
Laura presented on Tuesday.

I believe access to the spreadsheet is open to everybody, but if anybody runs 
into issues I'm sure Laura can help to grant access.


Tim

> 
> Robert (Bob) Monkman
> Enterprise Segment Marketing Manager
> 150 Rose Orchard Way
> San Jose, Ca 95134
> M: +1.510.676.5490
> 
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Thursday, February 04, 2016 2:16 PM
> To: dev at dpdk.org; Laura Kempke; Michael Dolan
> Subject: Re: [dpdk-dev] DPDK Community Call - Linux Foundation
> 
> Here are some brief minutes of our discussion on Tuesday. Apologies for
> the delay in sending these out.
> 
> Attendees: Bob Monkman, Bruce Richardson, Dave Neary, Ferruh Yigit, Jim
> St Leger, John Bromhead, John McNamara, Keith Wiles, Konstantin Ananyev,
> Laura Kempke, M Jay, Martin Horne, Mike Dolan, Mike Glynn, Tetsuya
> Mukawa, Thomas Monjalon, Tim O'Driscoll, Yoshihiro Nakajima
> Note: This list is taken from the GoToMeeting tool, but since people
> joined/left at different times it may not be complete.
> 
> 
> The background to the call is that we had a discussion at the Userspace
> event in Dublin on using Linux Foundation to provide a lightweight
> governance model for DPDK. This would cover marketing, event planning,
> trademarks, other legal issues etc. It would not cover any technical
> governance of the project.
> 
> Following this and a follow-up call we had in December, a small group of
> us (Dave Neary, Thomas Monjalon, Stephen Hemminger, Vincent Jardin, me)
> met with the Linux Foundation to create a draft budget which is
> available at: https://docs.google.com/spreadsheets/d/1-
> 3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256.
> 
> Laura walked through the spreadsheet at the meeting. Column B represents
> the minimum budget requirement for DPDK and totals $227k. Column C shows
> a number of optional additions and totals $766k. Points of discussion
> included:
> - The minimum option assumes that some of the event costs are covered by
> registration fees and sponsorship.
> - Jim asked about LF hosting DPDK IT infrastructure. This isn't
> currently included (row 23) but could be added if desired.
> - The item for hackathons (row 29) is just a placeholder. The general
> consensus seemed to be that we wouldn't need these.
> 
> Taking the minimum budget requirement of ~$227k, that would mean we'd be
> looking for ~10-15 companies to contribute, each paying a flat-rate
> membership fee of ~$15-25k.
> 
> There was a question on what member companies would get in return for
> their contribution. We need to do some further work on this, but the
> likelihood is that they would get a seat on a board which would
> determine how the DPDK budget is spent. The scope of this board would be
> limited to marketing/event/legal issues. Technical governance would
> continue to be handled separately via our Maintainers and our
> Architecture Board.
> 
> Most people on the call felt that the proposal to use LF was a good idea
> and was worth pursuing further. However, we only had a small number of
> people on the call so that may not be representative of the views of the
> entire community. Therefore, if anybody has further thoughts or input on
> this, please feel free to reply to this email.
> 
> Keith suggested holding a poll so that we can quantify the level of
> interest and give people a way to provide feedback anonymously in case
> they're unwilling to do so in public. I'll look into this.
> 
> Feel free to post any corrections or additions if I missed anything.
> 
> 
> Tim
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> > Sent: Saturday, January 23, 2016 12:19 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] DPDK Community Call - Linux Foundation
> >
> > At the community call we held on governance in December, we agreed
> that
> > a few of us would work with the Linux Foundation on a proposal for a
> > light-weight governance of DPDK. This would include things like

[dpdk-dev] DPDK Community Call - Linux Foundation

[O'Driscoll, Tim]

Here are some brief minutes of our discussion on Tuesday. Apologies for the 
delay in sending these out.

Attendees: Bob Monkman, Bruce Richardson, Dave Neary, Ferruh Yigit, Jim St 
Leger, John Bromhead, John McNamara, Keith Wiles, Konstantin Ananyev, Laura 
Kempke, M Jay, Martin Horne, Mike Dolan, Mike Glynn, Tetsuya Mukawa, Thomas 
Monjalon, Tim O'Driscoll, Yoshihiro Nakajima 
Note: This list is taken from the GoToMeeting tool, but since people 
joined/left at different times it may not be complete.


The background to the call is that we had a discussion at the Userspace event 
in Dublin on using Linux Foundation to provide a lightweight governance model 
for DPDK. This would cover marketing, event planning, trademarks, other legal 
issues etc. It would not cover any technical governance of the project.

Following this and a follow-up call we had in December, a small group of us 
(Dave Neary, Thomas Monjalon, Stephen Hemminger, Vincent Jardin, me) met with 
the Linux Foundation to create a draft budget which is available at: 
https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256.

Laura walked through the spreadsheet at the meeting. Column B represents the 
minimum budget requirement for DPDK and totals $227k. Column C shows a number 
of optional additions and totals $766k. Points of discussion included:
- The minimum option assumes that some of the event costs are covered by 
registration fees and sponsorship.
- Jim asked about LF hosting DPDK IT infrastructure. This isn't currently 
included (row 23) but could be added if desired.
- The item for hackathons (row 29) is just a placeholder. The general consensus 
seemed to be that we wouldn't need these.

Taking the minimum budget requirement of ~$227k, that would mean we'd be 
looking for ~10-15 companies to contribute, each paying a flat-rate membership 
fee of ~$15-25k.

There was a question on what member companies would get in return for their 
contribution. We need to do some further work on this, but the likelihood is 
that they would get a seat on a board which would determine how the DPDK budget 
is spent. The scope of this board would be limited to marketing/event/legal 
issues. Technical governance would continue to be handled separately via our 
Maintainers and our Architecture Board.

Most people on the call felt that the proposal to use LF was a good idea and 
was worth pursuing further. However, we only had a small number of people on 
the call so that may not be representative of the views of the entire 
community. Therefore, if anybody has further thoughts or input on this, please 
feel free to reply to this email.

Keith suggested holding a poll so that we can quantify the level of interest 
and give people a way to provide feedback anonymously in case they're unwilling 
to do so in public. I'll look into this.

Feel free to post any corrections or additions if I missed anything.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Saturday, January 23, 2016 12:19 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK Community Call - Linux Foundation
> 
> At the community call we held on governance in December, we agreed that
> a few of us would work with the Linux Foundation on a proposal for a
> light-weight governance of DPDK. This would include things like
> management of DPDK events, registering trademarks, and any required
> legal support etc.
> 
> Stephen, Thomas, Dave, Vincent and I met with the Linux Foundation to
> discuss this and came up with a draft budget proposal. We'd like to have
> a community call to discuss this and decide how we should proceed.
> 
> The current budget estimate is ~$227k. LF guidance is that for this size
> of budget they'd propose a flat membership fee (i.e. no tiered
> membership) of ~$25k per member company, with a target of getting 10 or
> more companies to contribute.
> 
> At the call we can discuss:
> - A breakdown of the proposed budget. LF are very flexible on this, so
> we can add or remove whatever we want for DPDK.
> - Proposed membership fee.
> - Matthew also highlight some recent changes to community representation
> at the Linux Foundation. We should discuss any concerns associated with
> this.
> - Next steps.
> 
> 
> When:
> Tue, Feb 2, 2015 15:00 - 16:00 GMT
> Tue, Feb 2, 2015 07:00 - 08:00 PST
> Tue, Feb 2, 2015 10:00 - 11:00 EST
> Tue, Feb 2, 2015 16:00 - 17:00 CET
> 
> 
> How to join:
> You can join from a computer, tablet or smartphone:
> https://global.gotomeeting.com/join/474154717
> 
> You can also dial in by phone.
> Access Code: 474-154-717
> 
> More phone numbers
> United States : +1 (312) 757-3126
> Australia : +61 2 9087 3604
> Austria : +43 7 2088 1400
> Belgium : +32 (0) 92 98 0592
> Canada : +1 (647) 497-9350

[dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto operations

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Saturday, January 30, 2016 1:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto
> operations
> 
> This patch provides the implementation of an AES-NI accelerated crypto
> PMD
> which is dependent on Intel's multi-buffer library, see the white paper
> "Fast Multi-buffer IPsec Implementations on Intel?  Architecture
> Processors"
> 
> This PMD supports AES_GCM authenticated encryption and authenticated
> decryption using
> 128-bit AES keys
> 
> The patch also contains the related unit tests functions for the
> implemented functionality
> 
> Signed-off-by: Declan Doherty 
> ---
>  MAINTAINERS|   4 +
>  app/test/test_cryptodev.c  | 462
> +++
>  app/test/test_cryptodev_gcm_test_vectors.h | 423
> +
>  config/common_linuxapp |  11 +-
>  config/defconfig_i686-native-linuxapp-gcc  |  10 +
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/aesni_gcm/Makefile  |  66 +++
>  drivers/crypto/aesni_gcm/aesni_gcm_ops.h   | 127 ++
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   | 498
> +
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   | 292 
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h   | 120 +
>  .../crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map |   3 +
>  lib/librte_cryptodev/rte_cryptodev.h   |   5 +
>  mk/rte.app.mk  |  11 +-
>  14 files changed, 2028 insertions(+), 5 deletions(-)
>  create mode 100644 app/test/test_cryptodev_gcm_test_vectors.h
>  create mode 100644 drivers/crypto/aesni_gcm/Makefile
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_ops.h
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
>  create mode 100644
> drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
> 

There should be an update to the Crypto Device Drivers guide for the new PMD.


Tim

[dpdk-dev] DPDK Community Call - Linux Foundation

[O'Driscoll, Tim]

At the community call we held on governance in December, we agreed that a few 
of us would work with the Linux Foundation on a proposal for a light-weight 
governance of DPDK. This would include things like management of DPDK events, 
registering trademarks, and any required legal support etc.

Stephen, Thomas, Dave, Vincent and I met with the Linux Foundation to discuss 
this and came up with a draft budget proposal. We'd like to have a community 
call to discuss this and decide how we should proceed.

The current budget estimate is ~$227k. LF guidance is that for this size of 
budget they'd propose a flat membership fee (i.e. no tiered membership) of 
~$25k per member company, with a target of getting 10 or more companies to 
contribute.

At the call we can discuss:
- A breakdown of the proposed budget. LF are very flexible on this, so we can 
add or remove whatever we want for DPDK.
- Proposed membership fee.
- Matthew also highlight some recent changes to community representation at the 
Linux Foundation. We should discuss any concerns associated with this.
- Next steps.


When: 
Tue, Feb 2, 2015 15:00 - 16:00 GMT
Tue, Feb 2, 2015 07:00 - 08:00 PST
Tue, Feb 2, 2015 10:00 - 11:00 EST
Tue, Feb 2, 2015 16:00 - 17:00 CET


How to join:
You can join from a computer, tablet or smartphone: 
https://global.gotomeeting.com/join/474154717

You can also dial in by phone.
Access Code: 474-154-717

More phone numbers
United States : +1 (312) 757-3126
Australia : +61 2 9087 3604
Austria : +43 7 2088 1400
Belgium : +32 (0) 92 98 0592
Canada : +1 (647) 497-9350
Denmark : +45 69 91 80 05
Finland : +358 (0) 942 41 5778
France : +33 (0) 182 880 456
Germany : +49 (0) 692 5736 7313
Ireland : +353 (0) 15 290 180
Italy : +39 0 247 92 12 39
Netherlands : +31 (0) 208 080 379
New Zealand : +64 9 442 7358
Norway : +47 21 03 58 96
Spain : +34 911 82 9782
Sweden : +46 (0) 313 613 558
Switzerland : +41 (0) 435 0006 96
United Kingdom : +44 (0) 20 3713 5028

[dpdk-dev] releases scheduling

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Saturday, December 19, 2015 8:14 PM
> To: Wiles, Keith
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] releases scheduling
> 
> 2015-12-19 16:21, Wiles, Keith:
> > On 12/19/15, 3:47 AM, "Thomas Monjalon" 
> wrote:
> > >2015-12-19 02:16, Wiles, Keith:
> > >> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" wrote:
> > >> >2015-12-13 20:22, Thomas Monjalon:
> > >> >> We need to define the deadlines for the next releases.
> > >> >> During 2015, we were doing a release every 4 months.
> > >> >> If we keep the same pace, the next releases would be:
> > >> >>   2.3: end of March
> > >> >>   2.4: end of July
> > >> >>   2.5: end of November
> > >> >>
> > >> >> However, things move fast and it may be a bit long to wait 4
> months for
> > >> >> a feature. That's why I suggest to progressively shorten release
> terms:
> > >> >>   2.3: end of March
> > >> >>   2.4: mid July
> > >> >>   2.5: end of October
> > >> >> and continue with a release every 3 months:
> > >> >>   2.6: end of January
> > >> >>   2.7: end of April
> > >> >>   2.8: end of July
> > >> >> This planning would preserve some of the major holiday periods
> > >> >> (February, May, August, December).
> > >> >>
> > >> >> The first period, for the first submission of a feature, was 2
> months long.
> > >> >> Then we had 2 other months to discuss, merge and fix.
> > >> >> We should shorten only the first period.
> > >> >>
> > >> >> Anyway, the next deadlines should be unchanged:
> > >> >>   - January 31: end of first submission phase
> > >> >>   - March 31: release 2.3
> > >> >>
> > >> >> Opinions are welcome.
> > >> >
> > >> >It seems everybody agree with this new scheduling.
> > >> >The web site will be updated accordingly:
> > >> >http://dpdk.org/ml/archives/web/2015-December/08.html
> > >> >
> > >> >There were some discussions to change the numbering scheme
> > >> >and rename 2.3 to 16.04. The patch (with arguments) is welcome.
> > >> >I won't do the patch myself because I don't care :)
> > >> >
> > >> >Another discussion was about having a long term support,
> > >> >i.e. doing some backport maintenance during a given period for
> > >> >some selected releases.
> > >>
> > >> I think we need to decide on the YY.MM.PP format then select
> > >> the dates for release now. This way we have it out of the way.
> > >>
> > >> The date of the release is the first day of the month for the
> release.
> > >>
> > >> March 1st - 15th is 16.03Patches for 16.03 are from now to Feb
> 15th
> > >> Try to get the release out as close to the 1st as possible.
> > >> This one is a short release.
> > >> June  1st - 15th is 16.06For 16.06 March 1st to May 15th
> > >> Sept  1st - 15th is 16.09For 16.09 June 1st to Aug 15th
> > >> Dec   1st - 15th is 16.12For 16.12 Sept 1st to Nov 15th.
> > >>
> > >> The 15th just before the release month is the deadline for patches,
> gives up 2 weeks before the release date and to the 15th of the release
> month to get the release out, but we should try for the 1st. The
> deadline is just a suggestion here or example, we can adjust it to
> something else.
> > >>
> > >> Tag 2.2.0 in the repo also as 15.12 plus I would suggest we tag it
> as LTS Long Term Support as well.
> > >
> > >Hi Keith,
> > >I'm confused. Have you read the proposal above and the patch above?
> > >I add it here again to make it more visible:
> > >   http://dpdk.org/ml/archives/web/2015-December/08.html
> > >And I copy-paste here:
> > >   The release cycles are progressively shorten during 2016.
> > >   Release 16.04
> > >   Proposal deadline: January 31
> > >   Integration deadline: March 10
> > >   Release: April 7
> > >   Release 16.07
> > >   Proposal deadline: May 8
> > >   Integration deadline: June 16
> > >   Release: July 18
> > >   Release 16.11
> > >   Proposal deadline: August 28
> > >   Integration deadline: September 30
> > >   Release: November 2
> > >   Release 17.02
> > >   Release: February 1
> > >   Release 17.05
> > >   Release: May 2
> > >   Release 17.08
> > >   Release: August 1
> > >   Release 17.11
> > >   Release: November 2
> >
> > Hi Thomas,
> >
> > The reason I keep stating my dates above is to make the release month
> the same each year not move them around each year. If we move the
> release months around it will be difficult to determine when the next
> release is to be done. I think we are both trying to increase the number
> of releases per year to reduce the work per release. I am trying to get
> a fixed release month each year just like Ubuntu has 04 and 10 each
> year.
> >
> > Please consider making the months fixed instead of having them move a
> bit each year.
> 
> Yes that's what I considered. The dates are not the same in 2016 and
> 2017
> 

[dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Keith
> Sent: Friday, December 18, 2015 7:23 PM
> To: Thomas Monjalon; Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] version: 2.3.0-rc0
> 
> On 12/18/15, 10:11 AM, "dev on behalf of Thomas Monjalon"  bounces at dpdk.org on behalf of thomas.monjalon at 6wind.com> wrote:
> 
> >2015-12-18 12:11, Bruce Richardson:
> >> On Thu, Dec 17, 2015 at 12:16:30PM +0100, Thomas Monjalon wrote:
> >> > Signed-off-by: Thomas Monjalon 
> >> > ---
> >> >  lib/librte_eal/common/include/rte_version.h | 6 +++---
> >> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/lib/librte_eal/common/include/rte_version.h
> b/lib/librte_eal/common/include/rte_version.h
> >> > index bb3e9fc..6b1890e 100644
> >> > --- a/lib/librte_eal/common/include/rte_version.h
> >> > +++ b/lib/librte_eal/common/include/rte_version.h
> >> > @@ -60,7 +60,7 @@ extern "C" {
> >> >  /**
> >> >   * Minor version number i.e. the y in x.y.z
> >> >   */
> >> > -#define RTE_VER_MINOR 2
> >> > +#define RTE_VER_MINOR 3
> >> >
> >> >  /**
> >> >   * Patch level number i.e. the z in x.y.z
> >> > @@ -70,14 +70,14 @@ extern "C" {
> >> >  /**
> >> >   * Extra string to be appended to version number
> >> >   */
> >> > -#define RTE_VER_SUFFIX ""
> >> > +#define RTE_VER_SUFFIX "-rc"
> >> >
> >> >  /**
> >> >   * Patch release number
> >> >   *   0-15 = release candidates
> >> >   *   16   = release
> >> >   */
> >> > -#define RTE_VER_PATCH_RELEASE 16
> >> > +#define RTE_VER_PATCH_RELEASE 0
> >> >
> >> >  /**
> >> >   * Macro to compute a version number usable for comparisons
> >>
> >> What about the discussion about the numbering of DPDK versions in
> future? The
> >> latest suggest which was +1'ed a number of times was to use an
> Ubuntu-style
> >> YY.MM naming scheme. I don't think there was any objections to such a
> scheme
> >> so is it not premature to start naming the new release now using the
> old scheme?
> >
> >Before doing any change on master, it is better to change the version
> number
> >to avoid confusion with the previous release. Example, the generated
> doc does
> >not show 2.2 anymore.
> >
> >About changing the numbering, no problem, it can be changed at any time
> before
> >the RC1. At the moment there was a proposal for YY.MM and a proposal
> for 3.0.
> >Even the YY.MM needs more discussion as it is not clear if we should
> use 15.03
> >or 15.04 for the release ending at the end of March. It seems
> reasonnable to
> >expect a release the next day, i.e. in April.
> 
> I believe the numbering should be 16.03, 16.06, 16.09 and 16.12. As for
> 2.2.0 we should give it a second name 15.12 == 2.2.0 (and add a label in
> Git), then we can start with 16.03 as the next release number. All
> efforts should be made to meet the months 3, 6, 9 and 12, if one happens
> to be into the next month for some reason then we still label and call
> it the correct release number.

When you say "the correct release number" I think you mean that if a release is 
planned for March but is actually completed in April, it would still be called 
16.03. I believe Ubuntu take the opposite approach, and if a release does slip 
it gets the number for the month it's actually completed in (16.04 in this 
example). There are advantages and disadvantages to both approaches. We'll need 
to decide which approach is best.

The best way to avoid confusion it to move from planning releases for the end 
of a month to planning them for the start of a month. So, as Thomas suggested 
above, we shouldn't plan our next release for the end of March, but for the 
start of April instead. That way it becomes 16.04, and we have a month of 
leeway in case there is a slip.

> 
> I would also suggest we label the 15.12 release as the Long Term Support
> (LTS), just to get a base line for the LTS. Then every 2 years(??) we
> have a new LTS release next one on 17.12, ...

+1 on this.


Tim

> 
> Keith
> >
> 
> 
> Regards,
> Keith
> 
> 
> 

[dpdk-dev] DPDK Community Call - Linux Foundation

[O'Driscoll, Tim]

These are brief minutes of our community call on Wednesday. Please feel free to 
post any corrections or additions.

Attendees:  Amruta Zende, Andrey, Bruce Richardson, Chris Wright, Dave Neary, 
Frank Zdarsky, Heqing Zhu, Jerin Jacob, Jim St Leger, John Bromhead, John 
DiGiglio, Keith Wiles, Konstantin Ananyev, Lixuming, M Jay, Mike Dolan, Nan, 
Panu Matilainen, Rashid Khan, Sanjay Aiyagari, Scott Nicholas, Siobhan Butler, 
Stephen Hemminger, Tao Yang, Thomas Monjalon, Tim O'Driscoll, Yoshihiro 
Nakajima.
Note: This list is taken from the GoToMeeting tool, but since people 
joined/left at different times it may not be complete.

Architecture Board:
- Discussed the proposal on board composition that was made recently on the 
mailing list (http://dpdk.org/ml/archives/dev/2015-December/030038.html).
- Stephen asked how frequently we should review membership. Agreed that we 
should review at least annually. Our next community event (we'll hold a 
follow-up to Userspace in Dublin in September-October) would be a good 
time/place to discuss how well this is working and any required changes.
- Jim asked if all the people nominated have confirmed that they're willing to 
participate. They have.

- Agreed that we now have an Architecture Board! The members will agree a time 
amongst themselves for a first meeting in January.
- Thanks to Thomas, Bruce, Stephen, Jerin, Panu, Olivier and Konstantin for 
agreeing to participate and provide technical direction for the project.


Linux Foundation:
- Mike Dolan presented the attached slides.
- Dave Neary asked if the LF model was all or nothing. Can a project pick and 
choose which elements it wants, or does it need to adopt the entire LF 
governance model? Mike confirmed that it's entirely up to each project which 
aspects they choose to adopt.
- There was some discussion on trademarks. As far as everybody on the call is 
aware, nobody has trademarked DPDK. Mike suggested that it's probably worth 
registering to prevent anybody else from doing so. LF can help with this 
process.
- There was a question on whether just the ownership of the dpdk.org domain 
would need to transition to LF, or if DNS would need to change too. Mike 
confirmed that it would just be a change in ownership of the domain and no DNS 
changes are required.
- Can you still have individuals who are not associated with an LF member 
participate as part of the decision-making process (e.g. a community rep on the 
board)? Mike confirmed that this is possible.
- Thomas asked about the scope of the project governance. Mike described it as 
a decision-making body that will determine how the project funds will be spent. 
This is completely separate from technical governance of the project, which 
we've dealt with separately via the Architecture Board.
- Agreed that we'll create a small team to work with the Linux Foundation to 
create a specific proposal for the project that will then be reviewed with the 
community. The following people volunteered on the call: Dave Neary, Thomas 
Monjalon, Stephen Hemminger, Tim O'Driscoll. If anybody else is interested in 
participating, please let me know. We did agree that we should keep this to a 
max of 5-6 people.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Thursday, December 10, 2015 11:02 PM
> To: Scott Nicholas; mdolan at linuxfoundation.org; dev at dpdk.org
> Subject: [dpdk-dev] DPDK Community Call - Linux Foundation
> 
> One of the actions resulting from the discussion we had on project
> governance at the Userspace event was to engage with the Linux
> Foundation to see if they can provide a lightweight model for DPDK. This
> would cover things like managing a marketing budget, event planning,
> trademarks etc. Scott Nicholas and Mike Dolan from the Linux Foundation
> will present the options that Linux Foundation can provide for DPDK.
> 
> Apologies for the short notice, but we'd like to fit this in before the
> holiday period.
> 
> When:
> Wed, Dec 16, 2015 15:00 - 16:00 GMT
> Wed, Dec 16, 2015 07:00 - 08:00 PST
> Wed, Dec 16, 2015 10:00 - 11:00 EST
> Wed, Dec 16, 2015 16:00 - 17:00 CET
> 
> How to join:
> You can join from your computer, tablet or smartphone:
> https://global.gotomeeting.com/join/497889365
> 
> You can also dial in using your phone.
> Access Code: 497-889-365
> 
> Phone numbers:
> United States : +1 (312) 757-3126
> Australia : +61 2 9087 3604
> Austria : +43 7 2088 0034
> Belgium : +32 (0) 28 93 7018
> Canada : +1 (647) 497-9350
> Denmark : +45 69 91 80 05
> Finland : +358 (0) 931 58 1746
> France : +33 (0) 182 880 780
> Germany : +49 (0) 692 5736 7211
> Ireland : +353 (0) 15 290 180
> Italy : +39 0 699 26 68 58
> Netherlands : +31 (0) 208 908 267
> New Zealand : +64 9 442 7358
> Norway : +47 21 54 32 44
> Spain : +34 911 23 0

[dpdk-dev] VFIO no-iommu

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Williamson
> Sent: Friday, December 11, 2015 11:03 PM
> To: Vincent JARDIN; dev at dpdk.org
> Subject: Re: [dpdk-dev] VFIO no-iommu
> 
> On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote:
> > Thanks Thomas for putting back this topic.
> >
> > Alex,
> >
> > I'd like to hear more about the impacts of "unsupported":
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi
> > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
> > ???Use of this mode, specifically binding a device without a native
> > ???IOMMU group to a VFIO bus driver will taint the kernel and should
> > ???therefore not be considered supported.
> >
> > It means that we get ride of uio; so it is a nice code cleanup: but
> > why
> > would VFIO/NO IOMMU be better if the bottomline is "unsupported"?
> 
> How supportable do you think the uio method is? ?Fundamentally we have
> a userspace driver doing unrestricted DMA; it can access and modify any
> memory in the system. ?This is the reason uio won't provide a mechanism
> to enable MSI and if you ask the uio maintainer, they don't support DMA
> at all, it's only intended as a programmed IO interface to the device.
> ?Unless we can sandbox a user owned device within an IOMMU protected
> container, it's not supportable. ?The VFIO no-iommu mode can simply
> provide you that unsupported mode more easily since it leverages code
> from the supported mode, which is IOMMU protected. ?Thanks,

Thanks for clarifying.

This does seem like it would be useful for DPDK. We're doing some further 
investigation to see if it works out of the box with DPDK or if we need to make 
any changes to support it.

Thomas highlighted that your original commit for this had been reverted. What 
specifically would you need from us in order to re-submit the VFIO No-IOMMU 
support?


Tim

> 
> Alex

[dpdk-dev] releases scheduling

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Sunday, December 13, 2015 7:23 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] releases scheduling
> 
> Hi all,
> 
> We need to define the deadlines for the next releases.
> During 2015, we were doing a release every 4 months.
> If we keep the same pace, the next releases would be:
>   2.3: end of March
>   2.4: end of July
>   2.5: end of November
> 
> However, things move fast and it may be a bit long to wait 4 months for
> a feature. That's why I suggest to progressively shorten release terms:
>   2.3: end of March
>   2.4: mid July
>   2.5: end of October
> and continue with a release every 3 months:
>   2.6: end of January
>   2.7: end of April
>   2.8: end of July
> This planning would preserve some of the major holiday periods
> (February, May, August, December).
> 
> The first period, for the first submission of a feature, was 2 months
> long.
> Then we had 2 other months to discuss, merge and fix.
> We should shorten only the first period.
> 
> Anyway, the next deadlines should be unchanged:
>   - January 31: end of first submission phase
>   - March 31: release 2.3
> 
> Opinions are welcome.

I think moving to quarterly releases is a good idea. Your proposal to do this 
in a gradual way, so that we don't change the 2.3 dates, also makes sense.

Should we consider changing the release numbering at the same time? It's 
difficult to keep track of when each 2.x release is due, and we don't have any 
criteria in place for moving to 3.x in future. Many people like the Ubuntu 
numbering scheme of Year.Month. Should we consider adopting that convention? If 
we move in future to a model where we have long-term support releases 
(something that was touched on in Dublin), then we could append an LTS 
designation to the release number.


Tim

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

Since we have agreement on the purpose and scope of the board, I'd like to make 
a proposal on the composition. I think the following people all have a strong 
history of contributions and technical credibility within the community, and 
represent a broad range of perspectives on DPDK: Stephen Hemminger, Thomas 
Monjalon, Olivier Matz, Panu Matilainen, Jerin Jacob, Bruce Richardson, 
Konstantin Ananyev.

I'd propose that this group have an initial meeting early in the new year. A 
good topic for a first meeting would be to clarify the scope of DPDK. We 
discussed this at the Userspace event (including questions such as whether an 
IPsec sample application is or is not within DPDK scope), and Venky agreed to 
draft an initial proposal, but due to other commitments he hasn't had time to 
do this yet. If Venky does get time to do this then his draft can be an input 
to the board for discussion/approval, otherwise I think the board members 
should just determine and document the scope themselves.

If anybody has comments on this or alternative proposals, please feel free to 
air them on the mailing list. We can also add this to the agenda for our 
community call on Wednesday and hopefully finalise it then.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Wednesday, November 18, 2015 5:55 PM
> To: 'dev at dpdk.org'
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> In order to progress this, I'd like to summarise what's been discussed
> on the mailing list so far (both in this thread and in the one Dave
> Neary started on governance proposals from the Userspace event) and give
> a final chance to people to provide any additional input. The main
> things that came up in the discussion were:
> 
> - We need to agree whether the scope of the board is just DPDK
> (http://dpdk.org/browse/dpdk/) or if it's all projects hosted on
> dpdk.org (http://dpdk.org/browse/). The consensus seemed to be just
> DPDK.
> 
> - It was reiterated that the board should only make decisions when a
> consensus isn't reached on the mailing this. This should not happen
> often, so the workload should be light.
> 
> - Membership needs to be based on contributions. There were requests for
> ARM SoC representation on the board, but most people felt that
> contributions should come from the SoC vendors first. Now that we're
> seeing more ARM-related contributions this may be less of an issue as we
> would have at least one ARM SoC rep to consider for membership based on
> recent contributions.
> 
> We do still have the difficult topic of membership to agree on. For now
> though, I want to make sure that we have agreement on the scope and
> purpose of the board. We can address membership once we've finalized
> that.
> 
> 
> Tim
> 
> > -Original Message-
> > From: O'Driscoll, Tim
> > Sent: Thursday, October 29, 2015 3:22 PM
> > To: dev at dpdk.org
> > Subject: Architecture Board Proposal
> >
> > At the recent DPDK Userspace event we agreed that we need a body to
> make
> > technical decisions for the project. In Dublin we referred to this as
> a
> > Technical Steering Committee, but that term is often used on other
> > projects to describe a body with a more political charter.  To avoid
> > confusion, and clarify that the scope of this body for DPDK is purely
> > technical, I propose calling it the DPDK Architecture Board.
> >
> > Justification
> > -
> > The role of the Maintainer is to be the gate-keeper for the project,
> and
> > to only accept contributions that are properly implemented, properly
> > reviewed, and consistent with the agreed project scope/charter.
> However,
> > it shouldn't be the responsibility of the Maintainer to be the final
> > decision maker (after community discussion) on issues affecting the
> > strategic direction of the project. Instead, this should be determined
> > by a higher level body that's representative of the DPDK community.
> >
> > Having an Architecture Board will help to provide a clear
> > direction/strategy for the project, and help to resolve complex issues
> > which don't reach a consensus on the mailing list in a timely manner.
> >
> > Scope
> > -
> > Issues that are within the scope of the Architecture Board include:
> > - Project scope/charter. What is and isn't within the scope of the
> > project? What happens if somebody wants to upstream a new
> > library/capability and it's not clear whether it fits within DPDK or
> > not? As a random example, if somebody wanted to upstream a DPDK-
> enabled
> > TCP/IP stack to dpdk.org, should that be accepted or rejected?

[dpdk-dev] DPDK Community Call - Linux Foundation

[O'Driscoll, Tim]

One of the actions resulting from the discussion we had on project governance 
at the Userspace event was to engage with the Linux Foundation to see if they 
can provide a lightweight model for DPDK. This would cover things like managing 
a marketing budget, event planning, trademarks etc. Scott Nicholas and Mike 
Dolan from the Linux Foundation will present the options that Linux Foundation 
can provide for DPDK.

Apologies for the short notice, but we'd like to fit this in before the holiday 
period.

When: 
Wed, Dec 16, 2015 15:00 - 16:00 GMT
Wed, Dec 16, 2015 07:00 - 08:00 PST
Wed, Dec 16, 2015 10:00 - 11:00 EST
Wed, Dec 16, 2015 16:00 - 17:00 CET

How to join:
You can join from your computer, tablet or smartphone: 
https://global.gotomeeting.com/join/497889365

You can also dial in using your phone.
Access Code: 497-889-365

Phone numbers:
United States : +1 (312) 757-3126
Australia : +61 2 9087 3604
Austria : +43 7 2088 0034
Belgium : +32 (0) 28 93 7018
Canada : +1 (647) 497-9350
Denmark : +45 69 91 80 05
Finland : +358 (0) 931 58 1746
France : +33 (0) 182 880 780
Germany : +49 (0) 692 5736 7211
Ireland : +353 (0) 15 290 180
Italy : +39 0 699 26 68 58
Netherlands : +31 (0) 208 908 267
New Zealand : +64 9 442 7358
Norway : +47 21 54 32 44
Spain : +34 911 23 0850
Sweden : +46 (0) 853 527 835
Switzerland : +41 (0) 435 0006 96
United Kingdom : +44 (0) 20 3713 5028

[dpdk-dev] DPDK Community Call - ARM Support

[O'Driscoll, Tim]

These are brief minutes of our community call on Tuesday. Please feel free to 
post any corrections or additions.

Attendees: Jim St Leger, Tim O'Driscoll, Konstantin Ananyev, Cheryl Edwards, 
Pablo de Lara Guarch, Declan Doherty, Mike Glynn, Dave Hunt, Bernard Iremonger, 
M Jay, Jerin Jacob (Cavium), Jitendra Kanitkar, John DiGiglio, John McNamara, 
Keith Wiles, Patrick Lu, Mike Holmes (Linaro), Olivier Matz, Prasun Kapoor, Raj 
Murali (Linaro), Remy Horton, Sergio Gonzalez Monroy, Thomas Monjalon, Walt 
Gilmore, Yoshihiro Nakajima, Siobhan Butler, Bob Monkman, Jan Viktorin, Ola 
Liljedahl (ARM), Ankit Jindal (Applied Micro), Fan Zhang
Note: This list is taken from the GoToMeeting tool, but since people 
joined/left at different times it may not be complete.


Jim gave a quick summary of last week's meeting:
- Dave Hunt summarized the status of ARM v7/v8 support. See the attached 
slides. Maintainers for v7 will be Jan Viktorin and Jianbo Liu. Maintainers for 
v8 will be Jerin Jacob and Jianbo Liu.
- Venky presented on External Mempool Manager. There wasn't time to complete 
the presentation so this was continued at this week's meeting.
- Bob Monkman is working on coordinating contributions to DPDK from the ARM 
community. 


External Mempool Manager:
- Keith Wiles completed the presentation on this. Slides are attached.
- Goal is to support other memory management schemes. These could be HW or SW 
implementations.
- People should review the slides and post any other comments/questions on the 
mailing list.


Bob gave an update on plans for DPDK contributions from the ARM community:
- The original plan was to consolidate/coordinate contributions across vendors, 
but it looks like this may not be necessary. This may change, but at the moment 
there doesn't seem to be a need.
- Several ARM vendors (including Broadcom, Freescale) are monitoring the work 
being done in DPDK. They'll test with their hardware and engage with the 
community if/when they have issues or patches to contribute
- Bob will get others to review External Mempool Manager proposal to make sure 
it meets their needs.


Call to discuss Linux Foundation options for DPDK:
- This is a follow up to a discussion at the Userspace event.
- Jim St Leger would like to have a Linux Foundation rep present to the 
community on the options for using LF for DPDK. We'll discuss with the LF and 
arrange a time for this, before the holiday period if possible.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Friday, December 4, 2015 5:51 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK Community Call - ARM Support
> 
> I missed Tuesday's call as I was travelling, but I believe one of the
> outcomes was to hold another call at the same time on Tuesday 8th to
> further discuss the External Mempool Manager. Here are the details:
> 
> When:
> Tue, Dec 8, 2015 15:00 - 16:00 GMT
> Tue, Dec 8, 2015 07:00 - 08:00 PST
> Tue, Dec 8, 2015 10:00 - 11:00 EST
> Tue, Dec 8, 2015 16:00 - 17:00 CET
> 
> How to join:
> You can join from your computer, tablet or smartphone:
> https://global.gotomeeting.com/join/704010829
> 
> You can also dial in using your phone.
> 
> Access Code: 704-010-829
> 
> Phone numbers
> United States : +1 (786) 358-5410
> Australia : +61 2 9087 3604
> Austria : +43 7 2088 0034
> Belgium : +32 (0) 28 93 7018
> Canada : +1 (647) 497-9350
> Denmark : +45 69 91 88 62
> Finland : +358 (0) 942 41 5778
> France : +33 (0) 182 880 456
> Germany : +49 (0) 692 5736 7211
> Ireland : +353 (0) 15 290 180
> Italy : +39 0 699 36 98 80
> Netherlands : +31 (0) 208 908 267
> New Zealand : +64 9 442 7358
> Norway : +47 21 54 32 44
> Spain : +34 911 23 0850
> Sweden : +46 (0) 853 527 835
> Switzerland : +41 (0) 435 0006 96
> United Kingdom : +44 (0) 20 3713 5028
-- next part --
A non-text attachment was scrubbed...
Name: Arm Status.pdf
Type: application/pdf
Size: 155149 bytes
Desc: Arm Status.pdf
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20151209/c41ee694/attachment-0002.pdf>
-- next part --
A non-text attachment was scrubbed...
Name: External Mempool Manager.pdf
Type: application/pdf
Size: 140199 bytes
Desc: External Mempool Manager.pdf
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20151209/c41ee694/attachment-0003.pdf>

[dpdk-dev] DPDK Community Call - ARM Support

[O'Driscoll, Tim]

I missed Tuesday's call as I was travelling, but I believe one of the outcomes 
was to hold another call at the same time on Tuesday 8th to further discuss the 
External Mempool Manager. Here are the details:

When: 
Tue, Dec 8, 2015 15:00 - 16:00 GMT
Tue, Dec 8, 2015 07:00 - 08:00 PST
Tue, Dec 8, 2015 10:00 - 11:00 EST
Tue, Dec 8, 2015 16:00 - 17:00 CET

How to join:
You can join from your computer, tablet or smartphone: 
https://global.gotomeeting.com/join/704010829

You can also dial in using your phone.

Access Code: 704-010-829

Phone numbers
United States : +1 (786) 358-5410
Australia : +61 2 9087 3604
Austria : +43 7 2088 0034
Belgium : +32 (0) 28 93 7018
Canada : +1 (647) 497-9350
Denmark : +45 69 91 88 62
Finland : +358 (0) 942 41 5778
France : +33 (0) 182 880 456
Germany : +49 (0) 692 5736 7211
Ireland : +353 (0) 15 290 180
Italy : +39 0 699 36 98 80
Netherlands : +31 (0) 208 908 267
New Zealand : +64 9 442 7358
Norway : +47 21 54 32 44
Spain : +34 911 23 0850
Sweden : +46 (0) 853 527 835
Switzerland : +41 (0) 435 0006 96
United Kingdom : +44 (0) 20 3713 5028

[dpdk-dev] 2.3 Roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
> Sent: Tuesday, December 1, 2015 1:00 PM
> To: O'Driscoll, Tim
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] 2.3 Roadmap
> 
> On Mon, Nov 30, 2015 at 08:50:58PM +, O'Driscoll, Tim wrote:
> > Increase Next Hops for LPM (IPv4): The number of next hops for IPv4
> LPM is
> > currently limited to 256. This will be extended to allow a greater
> number of
> > next hops.
> 
> In other threads, we previously proposed doing increased LPM4 *and*
> LPM6.
> 
> Having incompatible support between both is a huge headache for me.
> 
> And I already contributed patches to fix the issue in both versions.

True. The goal is to merge the best of the various patches that were submitted 
on this. This could involve changes to IPv6 as well as IPv4.


Tim

> 
> Thanks,
> Matthew

[dpdk-dev] 2.3 Roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dave Neary
> Sent: Monday, November 30, 2015 10:19 PM
> To: O'Driscoll, Tim; dev at dpdk.org
> Subject: Re: [dpdk-dev] 2.3 Roadmap
> 
> Hi Tim,
> 
> Just curious about one item on the list:
> 
> On 11/30/2015 03:50 PM, O'Driscoll, Tim wrote:
> > IPsec Sample Application: A sample application will be created which
> will show how DPDK and the new cryptodev API can be used to implement
> IPsec. Use of the cryptodev API will allow either hardware or software
> encryption to be used. IKE will not be implemented so the SA/SP DBs will
> be statically configured.
> 
> Do you anticipate this application living in the dpdk repo, or in a
> separate tree?

Good question. As a sample application showing how DPDK can be used to 
implement IPsec, I believe it belongs within the DPDK repo.

When we have an Architecture Board in place, I think one of the first tasks for 
the board should be to clarify the scope of DPDK. Venky agreed at the Userspace 
event to draft an initial statement on this. If the outcome of that is that the 
IPsec sample app doesn't belong within DPDK, then we can put it into a separate 
tree.


Tim
> 
> Thanks,
> Dave.
> 
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] 2.3 Roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: Hobywan Kenoby [mailto:hobywank at hotmail.com]
> Sent: Monday, November 30, 2015 10:30 PM
> To: O'Driscoll, Tim; dev at dpdk.org
> Subject: Re: 2.3 Roadmap
> 
> 
> Hi,
> 
> CAT And CDP technologies look very intriguing Could you elaborate a
> little on those?

We're working on a white paper which should be available soon. In the meantime, 
there's more information on these technologies at:
https://www-ssl.intel.com/content/www/us/en/communications/cache-monitoring-cache-allocation-technologies.html
https://01.org/packet-processing/cache-monitoring-technology-memory-bandwidth-monitoring-cache-allocation-technology-code-and-data


Tim

> 
> -HK
> ________
> From: dev  on behalf of O'Driscoll, Tim
> 
> Sent: Monday, November 30, 2015 9:50:58 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] 2.3 Roadmap
> 
> As we're nearing the completion of the 2.2 release, I'd like to start a
> discussion on plans for 2.3. To kick this off, below are the features
> that we're hoping to submit for this release.
> 
> If others are prepared to contribute their plans, then we could build a
> complete view of the release which Thomas can maintain on the dpdk.org
> roadmap page, and make sure we're not duplicating work.
> 
> 
> IPsec Sample Application: A sample application will be created which
> will show how DPDK and the new cryptodev API can be used to implement
> IPsec. Use of the cryptodev API will allow either hardware or software
> encryption to be used. IKE will not be implemented so the SA/SP DBs will
> be statically configured.
> 
> Cryptodev Support for SNOW 3G: The cryptodev API, and the hardware and
> software crypto PMDs that it supports, will be enhanced to support the
> SNOW 3G cipher.
> 
> External Mempool Manager: SoCs and some software applications that use
> DPDK have their own memory allocation capabilities. This feature will
> allow DPDK to work with an external mempool manager.
> 
> Packet Framework (Edge Router Use Case):
> - Further performance tuning for the vPE use case.
> - Support for load balancing within a pipeline.
> - Support for CPU utilization measurements within a pipeline.
> - Improvements for the functional pipelines, tables and ports.
> 
> Ethdev Enhancements: Merge parts of the Packet Framework ports library
> into ethdev so they can be used without the Packet Framework. The
> initial focus is to add support for buffered TX to ethdev.
> 
> Live Migration: The main infrastructure to support live migration of VMs
> was implemented over the last few DPDK releases via the Link Bonding and
> PCI Hot Plug features. This feature will involve further investigation,
> prototyping and enhancements to improve live migration support in DPDK.
> 
> Tcpdump Support: Support for tcpdump will be added to DPDK. This will
> improve usability and debugging of DPDK applications.
> 
> Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM
> is currently limited to 256. This will be extended to allow a greater
> number of next hops.
> 
> Fm10k Enhancements: FTAG based forwarding, and performance tuning
> 
> Support Intel Resource Director Technology: A library will be added to
> DPDK to support the following Intel CPU technologies:
> - CAT - Cache Allocation Technology (LLC aka L3)
> - CDP - Code Data Prioritization (extension of CAT)
> - CMT - Cache Monitoring Technology (LLC)
> - MBM - Memory Bandwidth Monitoring, to local and remote RAM
> These technologies are currently available via cgroups and perf, but
> this feature will provide closer integration with DPDK and a sample
> application showing how they can be used.
> 
> I40e Enhancements:
> - Flow Director input set Alignment
> - Ethertype configuration for QinQ support
> - Flow Director Support for Tunnels (QinQ, GRE/NVGRE, VXLAN)
> - Flow Director Support for IP Proto and IP TOS
> - VEB switching
> - Floating VEB
> - IPGRE Support
> - Set VF MAC address
> - Rework PCIe extended tag enabling by using DPDK interfaces
> 
> Virtio/Vhost Enhancements:
> - Virtio 1.0 support
> - Vhost software TSO
> - Vhost/virtio performance tuning
> 
> Container Enhancements:
> - Virtio for containers
> - Hugetlbfs mount point size
> - Cgroup resource awareness
> - Enable short-lived DPDK applications
> 
> Generic Tunneling API:
> - Implement virtual flow device framework
> - Implement generic virtual device management APIs, including the
> following callback functions:
>   - flow_ethdev_start/stop/configure/close/info_get
>   - ethdev_rx/tx_queue_setup/release
>   - flow_ethdev_tunnel_configure/setup/destroy
>   - flow_ethdev_tunnel_pkt_decap/encap
> - Implement flow device PMD drive APIs
>   - rte_eth_flow_dev_create/remove/ others
> - Integrate VXLAN protocol (including VXLAN decap/encap optimization)
> into this framework only on i40e.
> 
> 
> Tim

[dpdk-dev] 2.3 Roadmap

[O'Driscoll, Tim]

As we're nearing the completion of the 2.2 release, I'd like to start a 
discussion on plans for 2.3. To kick this off, below are the features that 
we're hoping to submit for this release.

If others are prepared to contribute their plans, then we could build a 
complete view of the release which Thomas can maintain on the dpdk.org roadmap 
page, and make sure we're not duplicating work.


IPsec Sample Application: A sample application will be created which will show 
how DPDK and the new cryptodev API can be used to implement IPsec. Use of the 
cryptodev API will allow either hardware or software encryption to be used. IKE 
will not be implemented so the SA/SP DBs will be statically configured.

Cryptodev Support for SNOW 3G: The cryptodev API, and the hardware and software 
crypto PMDs that it supports, will be enhanced to support the SNOW 3G cipher.

External Mempool Manager: SoCs and some software applications that use DPDK 
have their own memory allocation capabilities. This feature will allow DPDK to 
work with an external mempool manager.

Packet Framework (Edge Router Use Case):
- Further performance tuning for the vPE use case.
- Support for load balancing within a pipeline.
- Support for CPU utilization measurements within a pipeline.
- Improvements for the functional pipelines, tables and ports.

Ethdev Enhancements: Merge parts of the Packet Framework ports library into 
ethdev so they can be used without the Packet Framework. The initial focus is 
to add support for buffered TX to ethdev.

Live Migration: The main infrastructure to support live migration of VMs was 
implemented over the last few DPDK releases via the Link Bonding and PCI Hot 
Plug features. This feature will involve further investigation, prototyping and 
enhancements to improve live migration support in DPDK.

Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve 
usability and debugging of DPDK applications.

Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM is 
currently limited to 256. This will be extended to allow a greater number of 
next hops.

Fm10k Enhancements: FTAG based forwarding, and performance tuning

Support Intel Resource Director Technology: A library will be added to DPDK to 
support the following Intel CPU technologies:
- CAT - Cache Allocation Technology (LLC aka L3)
- CDP - Code Data Prioritization (extension of CAT)
- CMT - Cache Monitoring Technology (LLC)
- MBM - Memory Bandwidth Monitoring, to local and remote RAM
These technologies are currently available via cgroups and perf, but this 
feature will provide closer integration with DPDK and a sample application 
showing how they can be used.

I40e Enhancements:
- Flow Director input set Alignment
- Ethertype configuration for QinQ support
- Flow Director Support for Tunnels (QinQ, GRE/NVGRE, VXLAN)
- Flow Director Support for IP Proto and IP TOS
- VEB switching
- Floating VEB
- IPGRE Support
- Set VF MAC address
- Rework PCIe extended tag enabling by using DPDK interfaces

Virtio/Vhost Enhancements:
- Virtio 1.0 support
- Vhost software TSO
- Vhost/virtio performance tuning

Container Enhancements:
- Virtio for containers
- Hugetlbfs mount point size
- Cgroup resource awareness 
- Enable short-lived DPDK applications

Generic Tunneling API:
- Implement virtual flow device framework
- Implement generic virtual device management APIs, including the following 
callback functions:
  - flow_ethdev_start/stop/configure/close/info_get
  - ethdev_rx/tx_queue_setup/release
  - flow_ethdev_tunnel_configure/setup/destroy
  - flow_ethdev_tunnel_pkt_decap/encap
- Implement flow device PMD drive APIs
  - rte_eth_flow_dev_create/remove/ others
- Integrate VXLAN protocol (including VXLAN decap/encap optimization) into this 
framework only on i40e.


Tim

[dpdk-dev] DPDK Community Call - ARM Support

[O'Driscoll, Tim]

This is just a reminder that this call is on tomorrow, at 15:00 GMT. I'll be 
travelling, but Jim St Leger has agreed to host the call.

The agenda is:
ARMv7 & v8 ports:
- Summary of what's been submitted for 2.2 and what the remaining gaps are 
(Dave Hunt)
- Discussion on plans for further contributions in this area

External Memory Manager:
- Summary of our plans for DPDK 2.3 (Venky Venkatesan)
- Do others plan to do work in this area?

Other DPDK/ARM plans:
- Does anybody else have plans for ARM-related work in DPDK that they can share?

The link for the online meeting is: 
https://global.gotomeeting.com/join/535221101. Further details on the meeting 
time in other timezones, and dial-in numbers for various countries are included 
below.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Thursday, November 19, 2015 11:20 AM
> To: Bob Monkman; dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK Community Call - ARM Support
> 
> Thanks for following up on this Bob. It's great to see this level of
> engagement from the ARM ecosystem. In order to facilitate this, we'll
> move our call out by a week. New details for the meeting are:
> 
> When:
> Tue, Dec 1, 2015 15:00 - 16:00 GMT
> Tue, Dec 1, 2015 07:00 - 08:00 PST
> Tue, Dec 1, 2015 10:00 - 11:00 EST
> Tue, Dec 1, 2015 16:00 - 17:00 PST
> 
> Meeting Details:
> You can join from your computer, tablet or smartphone:
> https://global.gotomeeting.com/join/535221101
> 
> You can also dial in using your phone.
> 
> Access Code: 535-221-101
> 
> Phone numbers:
> United States: +1 (224) 501-3217
> Australia: +61 2 9087 3605
> Austria: +43 7 2088 1403
> Belgium: +32 (0) 28 93 7019
> Canada: +1 (647) 497-9351
> Denmark: +45 69 91 88 64
> Finland: +358 (0) 942 41 5781
> France: +33 (0) 182 880 458
> Germany: +49 (0) 692 5736 7210
> Ireland   +353 (0) 14 845 979
> Italy: +39 0 553 98 95 67
> Netherlands: +31 (0) 208 080 381
> New Zealand: +64 4 974 7214
> Norway: +47 21 03 58 98
> Spain: +34 955 32 0845
> Sweden: +46 (0) 853 527 836
> Switzerland: +41 (0) 435 0167 09
> United Kingdom: +44 (0) 330 221 0086
> 
> 
> Tim
> 
> > -Original Message-
> > From: Bob Monkman [mailto:Bob.Monkman at arm.com]
> > Sent: Wednesday, November 18, 2015 7:27 PM
> > To: O'Driscoll, Tim; dev at dpdk.org
> > Subject: RE: DPDK Community Call - ARM Support
> >
> > Tim, et al,
> > Thanks for this call to the ARM community to convene to
> discuss
> > what support is out there in ARM ecosystem. I am responsible for
> > networking segment software strategy within ARM and, as some of your
> > colleagues already know, I am coordinating collaborative work on DPDK
> > for ARM with multiple members of our ARM ecosystem.
> >
> > My concern on this first discussion is that I, and other key
> > stakeholders from engineering management will be out all week for the
> US
> > Thanksgiving holiday. I suspect other key ARM stakeholder reps who may
> > want to join in this conversation may be in the same boat. Would the
> > group here be willing to consider same day and time the following
> week?
> > Tuesday Dec 1?
> >
> > We would greatly appreciate and I think you will have a better
> > chance of critical mass of the right people.
> > Regards,
> > Bob
> >
> > Robert (Bob) Monkman
> > Enterprise Segment Marketing Manager
> > 150 Rose Orchard Way
> > San Jose, Ca 95134
> > M: +1.510.676.5490
> >
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> > Sent: Tuesday, November 17, 2015 9:09 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] DPDK Community Call - ARM Support
> >
> > There's been a lot of activity on the mailing list recently on DPDK
> > support for ARM. It's great to see the project being enhanced to
> embrace
> > a new architecture.
> >
> > We have seen some duplication of efforts on this, so we think it would
> > make a good topic for a community call. This will give everybody a
> > chance to share their plans so we can be clear on who's doing what and
> > make sure that we avoid overlaps.
> >
> > We'll host a community call on this next Tuesday (24th Nov) at 15:00-
> > 16:00 GMT. Details on the proposed agenda, the time in a couple of
> other
> > timezones, and how to join the online meeting are included below.
> >
> >
> > Agenda:
> > ARMv7 & v8 ports:
> > - Summary of what's been submitted for 2.2 and what the remaining gaps
> > are (Dave Hunt)

[dpdk-dev] DPDK Community Call - ARM Support

[O'Driscoll, Tim]

Thanks for following up on this Bob. It's great to see this level of engagement 
from the ARM ecosystem. In order to facilitate this, we'll move our call out by 
a week. New details for the meeting are:

When:
Tue, Dec 1, 2015 15:00 - 16:00 GMT
Tue, Dec 1, 2015 07:00 - 08:00 PST
Tue, Dec 1, 2015 10:00 - 11:00 EST
Tue, Dec 1, 2015 16:00 - 17:00 PST

Meeting Details:
You can join from your computer, tablet or smartphone:
https://global.gotomeeting.com/join/535221101

You can also dial in using your phone.

Access Code: 535-221-101

Phone numbers:
United States: +1 (224) 501-3217
Australia: +61 2 9087 3605
Austria: +43 7 2088 1403
Belgium: +32 (0) 28 93 7019
Canada: +1 (647) 497-9351
Denmark: +45 69 91 88 64
Finland: +358 (0) 942 41 5781
France: +33 (0) 182 880 458
Germany: +49 (0) 692 5736 7210
Ireland   +353 (0) 14 845 979
Italy: +39 0 553 98 95 67
Netherlands: +31 (0) 208 080 381
New Zealand: +64 4 974 7214
Norway: +47 21 03 58 98
Spain: +34 955 32 0845
Sweden: +46 (0) 853 527 836
Switzerland: +41 (0) 435 0167 09
United Kingdom: +44 (0) 330 221 0086


Tim

> -Original Message-
> From: Bob Monkman [mailto:Bob.Monkman at arm.com]
> Sent: Wednesday, November 18, 2015 7:27 PM
> To: O'Driscoll, Tim; dev at dpdk.org
> Subject: RE: DPDK Community Call - ARM Support
> 
> Tim, et al,
> Thanks for this call to the ARM community to convene to discuss
> what support is out there in ARM ecosystem. I am responsible for
> networking segment software strategy within ARM and, as some of your
> colleagues already know, I am coordinating collaborative work on DPDK
> for ARM with multiple members of our ARM ecosystem.
> 
> My concern on this first discussion is that I, and other key
> stakeholders from engineering management will be out all week for the US
> Thanksgiving holiday. I suspect other key ARM stakeholder reps who may
> want to join in this conversation may be in the same boat. Would the
> group here be willing to consider same day and time the following week?
> Tuesday Dec 1?
> 
> We would greatly appreciate and I think you will have a better
> chance of critical mass of the right people.
> Regards,
> Bob
> 
> Robert (Bob) Monkman
> Enterprise Segment Marketing Manager
> 150 Rose Orchard Way
> San Jose, Ca 95134
> M: +1.510.676.5490
> 
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Tuesday, November 17, 2015 9:09 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK Community Call - ARM Support
> 
> There's been a lot of activity on the mailing list recently on DPDK
> support for ARM. It's great to see the project being enhanced to embrace
> a new architecture.
> 
> We have seen some duplication of efforts on this, so we think it would
> make a good topic for a community call. This will give everybody a
> chance to share their plans so we can be clear on who's doing what and
> make sure that we avoid overlaps.
> 
> We'll host a community call on this next Tuesday (24th Nov) at 15:00-
> 16:00 GMT. Details on the proposed agenda, the time in a couple of other
> timezones, and how to join the online meeting are included below.
> 
> 
> Agenda:
> ARMv7 & v8 ports:
> - Summary of what's been submitted for 2.2 and what the remaining gaps
> are (Dave Hunt)
> - Discussion on plans for further contributions in this area
> 
> External Memory Manager:
> - Summary of our plans for DPDK 2.3 (Venky Venkatesan)
> - Do others plan to do work in this area?
> 
> Other DPDK/ARM plans:
> - Does anybody else have plans for ARM-related work in DPDK that they
> can share?
> 
> 
> When:
> Tue, Nov 24, 2015 15:00 - 16:00 GMT
> Tue, Nov 24, 2015 07:00 - 08:00 PST
> Tue, Nov 24, 2015 10:00 - 11:00 EST
> Tue, Nov 24, 2015 16:00 - 17:00 PST
> 
> 
> Meeting Details:
> You can join from your computer, tablet or smartphone:
> https://global.gotomeeting.com/join/535221101
> 
> You can also dial in using your phone.
> 
> Access Code: 535-221-101
> 
> Phone numbers:
> United States: +1 (224) 501-3217
> Australia: +61 2 9087 3605
> Austria: +43 7 2088 1403
> Belgium: +32 (0) 28 93 7019
> Canada: +1 (647) 497-9351
> Denmark: +45 69 91 88 64
> Finland: +358 (0) 942 41 5781
> France: +33 (0) 182 880 458
> Germany: +49 (0) 692 5736 7210
> Ireland   +353 (0) 14 845 979
> Italy: +39 0 553 98 95 67
> Netherlands: +31 (0) 208 080 381
> New Zealand: +64 4 974 7214
> Norway: +47 21 03 58 98
> Spain: +34 955 32 0845
> Sweden: +46 (0) 853 527 836
> Switzerland: +41 (0) 435 0167 09
> United Kingdom: +44 (0) 330 221 0086
> 
> 
> 
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
> the information in any medium. Thank you.

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

In order to progress this, I'd like to summarise what's been discussed on the 
mailing list so far (both in this thread and in the one Dave Neary started on 
governance proposals from the Userspace event) and give a final chance to 
people to provide any additional input. The main things that came up in the 
discussion were:

- We need to agree whether the scope of the board is just DPDK 
(http://dpdk.org/browse/dpdk/) or if it's all projects hosted on dpdk.org 
(http://dpdk.org/browse/). The consensus seemed to be just DPDK.

- It was reiterated that the board should only make decisions when a consensus 
isn't reached on the mailing this. This should not happen often, so the 
workload should be light.

- Membership needs to be based on contributions. There were requests for ARM 
SoC representation on the board, but most people felt that contributions should 
come from the SoC vendors first. Now that we're seeing more ARM-related 
contributions this may be less of an issue as we would have at least one ARM 
SoC rep to consider for membership based on recent contributions.

We do still have the difficult topic of membership to agree on. For now though, 
I want to make sure that we have agreement on the scope and purpose of the 
board. We can address membership once we've finalized that.


Tim

> -Original Message-
> From: O'Driscoll, Tim
> Sent: Thursday, October 29, 2015 3:22 PM
> To: dev at dpdk.org
> Subject: Architecture Board Proposal
> 
> At the recent DPDK Userspace event we agreed that we need a body to make
> technical decisions for the project. In Dublin we referred to this as a
> Technical Steering Committee, but that term is often used on other
> projects to describe a body with a more political charter.  To avoid
> confusion, and clarify that the scope of this body for DPDK is purely
> technical, I propose calling it the DPDK Architecture Board.
> 
> Justification
> -
> The role of the Maintainer is to be the gate-keeper for the project, and
> to only accept contributions that are properly implemented, properly
> reviewed, and consistent with the agreed project scope/charter. However,
> it shouldn't be the responsibility of the Maintainer to be the final
> decision maker (after community discussion) on issues affecting the
> strategic direction of the project. Instead, this should be determined
> by a higher level body that's representative of the DPDK community.
> 
> Having an Architecture Board will help to provide a clear
> direction/strategy for the project, and help to resolve complex issues
> which don't reach a consensus on the mailing list in a timely manner.
> 
> Scope
> -
> Issues that are within the scope of the Architecture Board include:
> - Project scope/charter. What is and isn't within the scope of the
> project? What happens if somebody wants to upstream a new
> library/capability and it's not clear whether it fits within DPDK or
> not? As a random example, if somebody wanted to upstream a DPDK-enabled
> TCP/IP stack to dpdk.org, should that be accepted or rejected?
> - Performance vs functionality considerations. If we need to make a
> change and there's an unavoidable performance impact to doing so (maybe
> something like extending the mbuf again), does that change get accepted
> or not? In most cases you can probably work around situations like this
> by making them optional, but that might not always be possible. If it's
> not, who decides whether performance or functionality is more important?
> - Replacing existing functionality versus adding new alternatives. If
> there's a new implementation of an existing DPDK capability that
> performs better in some use cases but worse in others, does that get
> accepted and replace the existing implementation, does it get accepted
> as an alternative, or does it get rejected?
> - Unresolved issues. Provide a decision on issues that don't reach a
> consensus on the mailing list in a timely manner.
> 
> Composition
> ---
> For composition of the Architecture Board, I'd propose the following:
> - It needs to be kept to a manageable size. I propose limiting it to 5
> initially (it should be an odd number to minimize deadlocks).
> - Membership should be based on: number and quality of contributions,
> technical standing in the community, breadth of involvement (involvement
> in many areas, not just a single part of DPDK).
> - No single company/organization can have more than 2 members.
> - The Architecture Board will elect its own chair, who will have the
> deciding vote in the event of a deadlock.
> - The board will review its own composition and co-opt/approve any new
> members on an annual basis.
> 
> There are three main options for determining who is on the board:
> 1. Nomination of representatives 

[dpdk-dev] DPDK Community Call - ARM Support

[O'Driscoll, Tim]

There's been a lot of activity on the mailing list recently on DPDK support for 
ARM. It's great to see the project being enhanced to embrace a new architecture.

We have seen some duplication of efforts on this, so we think it would make a 
good topic for a community call. This will give everybody a chance to share 
their plans so we can be clear on who's doing what and make sure that we avoid 
overlaps.

We'll host a community call on this next Tuesday (24th Nov) at 15:00-16:00 GMT. 
Details on the proposed agenda, the time in a couple of other timezones, and 
how to join the online meeting are included below.


Agenda:
ARMv7 & v8 ports:
- Summary of what's been submitted for 2.2 and what the remaining gaps are 
(Dave Hunt)
- Discussion on plans for further contributions in this area

External Memory Manager:
- Summary of our plans for DPDK 2.3 (Venky Venkatesan)
- Do others plan to do work in this area?

Other DPDK/ARM plans:
- Does anybody else have plans for ARM-related work in DPDK that they can share?


When: 
Tue, Nov 24, 2015 15:00 - 16:00 GMT
Tue, Nov 24, 2015 07:00 - 08:00 PST
Tue, Nov 24, 2015 10:00 - 11:00 EST
Tue, Nov 24, 2015 16:00 - 17:00 PST


Meeting Details:
You can join from your computer, tablet or smartphone: 
https://global.gotomeeting.com/join/535221101

You can also dial in using your phone. 

Access Code: 535-221-101 

Phone numbers:
United States: +1 (224) 501-3217   
Australia: +61 2 9087 3605   
Austria: +43 7 2088 1403   
Belgium: +32 (0) 28 93 7019   
Canada: +1 (647) 497-9351   
Denmark: +45 69 91 88 64   
Finland: +358 (0) 942 41 5781   
France: +33 (0) 182 880 458   
Germany: +49 (0) 692 5736 7210   
Ireland   +353 (0) 14 845 979   
Italy: +39 0 553 98 95 67   
Netherlands: +31 (0) 208 080 381   
New Zealand: +64 4 974 7214   
Norway: +47 21 03 58 98   
Spain: +34 955 32 0845   
Sweden: +46 (0) 853 527 836   
Switzerland: +41 (0) 435 0167 09   
United Kingdom: +44 (0) 330 221 0086

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[O'Driscoll, Tim]

> -Original Message-
> From: Pradeep Kathail [mailto:pkathail at cisco.com]
> Sent: Monday, November 2, 2015 11:16 PM
> To: O'Driscoll, Tim; Bagh Fares; Dave Neary; CHIOSI, MARGARET T; Stephen
> Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> DPDK Userspace (was Notes from ...)
> 
> Tim and Dave,
> 
> I agree that an architecture board membership should be based on
> technical standing and contribution but at the same time,
> if you are trying to bring a new hardware paradigm into a project, you
> need to give a chance to some of those experts to
> participate and gain the standing.
> 
> If community is serious about supporting SOC's, my suggestion will be
> to allow few (2?) members from SOC community for
> limited time (6? months) and then evaluate based on their contributions.

I think we might be talking about 2 slightly different things. You're asking 
how new contributors can participate and gain technical credibility. Anybody 
can do that via the dev at dpdk.org mailing list. I'm sure patches, RFCs or 
discussions on changes required in DPDK to better facilitate SoCs will be 
welcomed. There have been some good examples of this over the last few days on 
ARMv7/v8 support and a NEON-based ACL implementation.

The Architecture Board isn't intended as a forum for design discussions, which 
I think might be what you're looking for. It's intended to meet only 
occasionally to cover the items outlined in the proposal. We discussed 
composition of the board recently in Dublin and the community decided that, 
while users and potential contributors have an important role to play in the 
project, it should be composed solely of contributors. Dave Neary summed it up 
well in a previous email on this: "The TSC should be representative of the 
technical contributors to the project, rather than an aspirational body aiming 
to get more people involved."

It would be interesting to hear the thoughts of others on whether we should 
consider an exception in this case.


Tim

> 
> Pradeep
> 
> On 11/2/15 1:44 PM, O'Driscoll, Tim wrote:
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bagh Fares
> >> Sent: Monday, November 2, 2015 6:03 PM
> >> To: Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger
> >> Cc: dev at dpdk.org; Pradeep Kathail (pkathail at cisco.com)
> >> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> >> DPDK Userspace (was Notes from ...)
> >>
> >> Yes. Thank you. What we like is to get to a point where we discuss
> API
> >> and align on APIs for SOC as Margaret mention. As you know Arm has
> been
> >> driving ODP as the API for SOC.
> >> What we like to do is to drive the APIs under DPDK even for Arm SOC.
> >> Long term, and based on shrinking silicon geometries, and desire to
> fill
> >> fabs, Intel will do more SOCs. I was SOC design manager in Intel :-)
> >> We like to spare the customers like red hat, Cisco, and ATT the pain
> of
> >> supporting multiple APIs and code bases.
> > That's our goal too, so it's good to hear that we're in agreement on
> this.
> >
> >> So we need have a forum/place where this can be worked at .
> > If you have some ideas, then the best way to get some discussion going
> is through the mailing list. You could post a set of patches for
> proposed changes, a higher-level RFC outlining your thoughts, or just
> specific questions/issues that you see.
> >
> > On the TSC that was specifically referenced earlier in this thread,
> there is a proposal for what we're now calling the Architecture Board
> at: http://dpdk.org/ml/archives/dev/2015-October/026598.html. As Dave
> mentioned, we agreed at our recent Userspace event in Dublin that
> membership of the board should be based on contributions and technical
> standing in the community. The board will review and approve new members
> on an annual basis.
> >
> >> We are reaching out and we like to feel welcome and some love :-)
> > As Thomas already said, new contributors are always welcome!
> >
> >
> > Tim
> >
> >
> >> -Original Message-
> >> From: Dave Neary [mailto:dneary at redhat.com]
> >> Sent: Monday, November 02, 2015 11:55 AM
> >> To: Bagh Fares-B25033 ; CHIOSI, MARGARET T
> >> ; Stephen Hemminger 
> >> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
> >> (pkathail at cisco.com) 
> >> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> >> DPDK Userspace (was Notes from ...)
> >>
> >> Hi,
> >>

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bagh Fares
> Sent: Monday, November 2, 2015 6:03 PM
> To: Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger
> Cc: dev at dpdk.org; Pradeep Kathail (pkathail at cisco.com)
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> DPDK Userspace (was Notes from ...)
> 
> Yes. Thank you. What we like is to get to a point where we discuss API
> and align on APIs for SOC as Margaret mention. As you know Arm has been
> driving ODP as the API for SOC.
> What we like to do is to drive the APIs under DPDK even for Arm SOC.
> Long term, and based on shrinking silicon geometries, and desire to fill
> fabs, Intel will do more SOCs. I was SOC design manager in Intel :-)
> We like to spare the customers like red hat, Cisco, and ATT the pain of
> supporting multiple APIs and code bases.

That's our goal too, so it's good to hear that we're in agreement on this.

> So we need have a forum/place where this can be worked at .

If you have some ideas, then the best way to get some discussion going is 
through the mailing list. You could post a set of patches for proposed changes, 
a higher-level RFC outlining your thoughts, or just specific questions/issues 
that you see.

On the TSC that was specifically referenced earlier in this thread, there is a 
proposal for what we're now calling the Architecture Board at: 
http://dpdk.org/ml/archives/dev/2015-October/026598.html. As Dave mentioned, we 
agreed at our recent Userspace event in Dublin that membership of the board 
should be based on contributions and technical standing in the community. The 
board will review and approve new members on an annual basis.

> We are reaching out and we like to feel welcome and some love :-)

As Thomas already said, new contributors are always welcome!


Tim


> 
> -Original Message-
> From: Dave Neary [mailto:dneary at redhat.com]
> Sent: Monday, November 02, 2015 11:55 AM
> To: Bagh Fares-B25033 ; CHIOSI, MARGARET T
> ; Stephen Hemminger 
> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
> (pkathail at cisco.com) 
> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> DPDK Userspace (was Notes from ...)
> 
> Hi,
> 
> On the contrary! I am aware that Freescale has been engaged for some
> time in DPDK. I was responding to Margaret's contention that future
> contributors (and she called out ARM and SOC vendors) should have a
> voice.
> 
> I hope that clarifies my position and meaning.
> 
> Thanks,
> Dave.
> 
> On 11/02/2015 12:44 PM, Bagh Fares wrote:
> > As SOC vendor we will contribute heavily to the project. Example
> crypto acceleration. We already contribute a lot to the linux community.
> > So not sure why the doubt about of contribution?
> >
> >
> > -Original Message-
> > From: Dave Neary [mailto:dneary at redhat.com]
> > Sent: Monday, November 02, 2015 11:31 AM
> > To: CHIOSI, MARGARET T ; Stephen Hemminger
> > ; Bagh Fares-B25033
> > 
> > Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail
> > (pkathail at cisco.com) 
> > Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> > DPDK Userspace (was Notes from ...)
> >
> > Hi Margaret,
> >
> > On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote:
> >> I think it is very important for the first version of governance that
> we have ARM/SOC vendor/future contributors to be part of TSC.
> >> If based on historical contribution - they will be at a disadvantage.
> >> We need to have the DPDK organization support an API which supports a
> broader set of chips.
> >
> > I think there is definitely a role for SOC vendors in the project
> governance, but the TSC should be representative of the technical
> contributors to the project, rather than an aspirational body aiming to
> get more people involved.
> >
> > I think there is an opportunity for future contributors/users to form
> a powerful constituency in the project, but the TSC is not the right
> place for that to happen IMHO.
> >
> > Thanks,
> > Dave.
> >
> >> -Original Message-
> >> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> >> Sent: Monday, November 02, 2015 12:22 PM
> >> To: Bagh Fares
> >> Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; 
> >> Pradeep
> >> Kathail (pkathail at cisco.com); CHIOSI, MARGARET T
> >> Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> >> DPDK Userspace (was Notes from ...)
> >>
> >> There were two outcomes.
> >>
> >> One was a proposal to move governance under Linux Foundation.
> >>
> >> The other was to have a technical steering committee.
> >> It was agreed the TSC would be based on the contributors to the
> >> project, although we didn't come to a conclusion on a voting model.
> >>
> >>
> >> I would propose that TSC should be elected at regular user summit
> >> from nominees; in a manner similar to LF Technical Advisory Board.
> >>
> >
> > --
> > Dave Neary - 

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dave Neary
> Sent: Friday, October 30, 2015 1:11 PM
> To: O'Driscoll, Tim; dev at dpdk.org
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> Hi,
> 
> On 10/30/2015 07:01 AM, O'Driscoll, Tim wrote:
> >>> Scope
> >>> -
> >>> Issues that are within the scope of the Architecture Board include:
> >>> - Project scope/charter. What is and isn't within the scope of the
> >>>   project? What happens if somebody wants to upstream a new
> >>>   library/capability and it's not clear whether it fits within DPDK
> or
> >>>   not? As a random example, if somebody wanted to upstream a DPDK-
> >> enabled
> >>>   TCP/IP stack to dpdk.org, should that be accepted or rejected?
> >>
> >> I agree with Thomas here that this seems like it would be a separate
> >> project under dpdk.org, rather than part of DPDK - I think it's OK
> for
> >> the Architecture Board to own the scope of "projects on dpdk.org"
> rather
> >> than just DPDK.
> >
> > I think there are two questions here. The first is one that Thomas
> raised and you've also touched on: Is the scope of the Architecture
> Board just DPDK (i.e. everything in http://dpdk.org/browse/dpdk/), or is
> it everything hosted on dpdk.org (list at: http://dpdk.org/browse/). My
> original intent was just DPDK, but I'm fine with either option.
> >
> > The second question is who decides whether something is within the
> scope of DPDK or not? A TCP/IP stack was just an example. If I were to
> submit patches for a DPDK-accelerated IPsec library (librte_ipsec), who
> would decide whether that's OK or if it needs to reside somewhere else
> outside of the DPDK? I think that managing the scope of the project
> should be one of the roles of the Architecture Board.
> 
> The issue I see is that if we agree that the architecture board's scope
> is limited to DPDK only, and the architecture board owns the scope of
> DPDK, that we still have the open question of which projects are
> appropriate to be housed under dpdk.org
> 
> There was a general agreement in Dublin that DPDK related projects and
> applications could live in dpdk.org, but we didn't really touch on the
> process or requirements for adding new projects. I think it's
> appropriate for the architecture board to own those too.
> 

That makes sense. So maybe what we're converging on is the following:
- The scope of the Architecture Board covers all projects hosted on dpdk.org.
- The Architecture Board will approve new projects to be hosted on dpdk.org.
- If it's not clear whether a new piece of functionality resides within one of 
the existing projects on dpdk.org or needs a new project of its own, the 
Architecture Board will decide.

Is that in line with your thoughts on this?


Tim

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

> -Original Message-
> From: Dave Neary [mailto:dneary at redhat.com]
> Sent: Thursday, October 29, 2015 7:49 PM
> To: O'Driscoll, Tim; dev at dpdk.org
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> Thanks Tim,
> 
> Great to see some momentum coming out of DPDK Userspace.
> 
> On 10/29/2015 11:21 AM, O'Driscoll, Tim wrote:
> > At the recent DPDK Userspace event we agreed that we need a body to
> > make technical decisions for the project. In Dublin we referred to
> this
> > as a Technical Steering Committee, but that term is often used on
> other
> > projects to describe a body with a more political charter. To avoid
> > confusion, and clarify that the scope of this body for DPDK is purely
> > technical, I propose calling it the DPDK Architecture Board.
> 
> Speaking personally, I don't mind what we call it once there is an
> agreed scope, membership process, and decision making process.
> Architecture Board seems OK to me.
> 
> > Justification
> > -
> > The role of the Maintainer is to be the gate-keeper for the project,
> > and to only accept contributions that are properly implemented,
> properly
> > reviewed, and consistent with the agreed project scope/charter.
> However,
> > it shouldn't be the responsibility of the Maintainer to be the final
> > decision maker (after community discussion) on issues affecting the
> > strategic direction of the project. Instead, this should be determined
> > by a higher level body that's representative of the DPDK community.
> >
> > Having an Architecture Board will help to provide a clear
> > direction/strategy for the project, and help to resolve complex issues
> > which don't reach a consensus on the mailing list in a timely manner.
> >
> > Scope
> > -
> > Issues that are within the scope of the Architecture Board include:
> > - Project scope/charter. What is and isn't within the scope of the
> >   project? What happens if somebody wants to upstream a new
> >   library/capability and it's not clear whether it fits within DPDK or
> >   not? As a random example, if somebody wanted to upstream a DPDK-
> enabled
> >   TCP/IP stack to dpdk.org, should that be accepted or rejected?
> 
> I agree with Thomas here that this seems like it would be a separate
> project under dpdk.org, rather than part of DPDK - I think it's OK for
> the Architecture Board to own the scope of "projects on dpdk.org" rather
> than just DPDK.

I think there are two questions here. The first is one that Thomas raised and 
you've also touched on: Is the scope of the Architecture Board just DPDK (i.e. 
everything in http://dpdk.org/browse/dpdk/), or is it everything hosted on 
dpdk.org (list at: http://dpdk.org/browse/). My original intent was just DPDK, 
but I'm fine with either option.

The second question is who decides whether something is within the scope of 
DPDK or not? A TCP/IP stack was just an example. If I were to submit patches 
for a DPDK-accelerated IPsec library (librte_ipsec), who would decide whether 
that's OK or if it needs to reside somewhere else outside of the DPDK? I think 
that managing the scope of the project should be one of the roles of the 
Architecture Board.

> > - Performance vs functionality considerations. If we need to make a
> >   change and there's an unavoidable performance impact to doing so
> (maybe
> >   something like extending the mbuf again), does that change get
> accepted
> >   or not? In most cases you can probably work around situations like
> this
> >   by making them optional, but that might not always be possible. If
> it's
> >   not, who decides whether performance or functionality is more
> important?
> > - Replacing existing functionality versus adding new alternatives.
> >   If there's a new implementation of an existing DPDK capability that
> >   performs better in some use cases but worse in others, does that get
> >   accepted and replace the existing implementation, does it get
> accepted
> >   as an alternative, or does it get rejected?
> > - Unresolved issues. Provide a decision on issues that don't reach a
> >   consensus on the mailing list in a timely manner.
> 
> In general I would summarise these as "act as a decision making body
> when there is a difficulty converging to a decision in the community".
> That includes competing technology, priorities and in general
> non-converging discussions.
> 
> I think it's important to say that this body kicks in after a decision
> has not converged, it is not (apart from project scope considerations,
> wich will not evolve very often) a leading body, rather, it's a "last
&

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, October 29, 2015 3:43 PM
> To: O'Driscoll, Tim
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> Hi Tim,
> 
> 2015-10-29 15:21, O'Driscoll, Tim:
> > Scope
> > -
> > Issues that are within the scope of the Architecture Board include:
> > - Project scope/charter. What is and isn't within the scope of the
> project? What happens if somebody wants to upstream a new
> library/capability and it's not clear whether it fits within DPDK or
> not? As a random example, if somebody wanted to upstream a DPDK-enabled
> TCP/IP stack to dpdk.org, should that be accepted or rejected?
> 
> Do you mean the scope of this board would be about the whole projects
> hosted
> on dpdk.org (http://dpdk.org/browse/) or only the DPDK
> (http://dpdk.org/browse/dpdk)?
> 
> Using your TCP stack example, I think it should be hosted on dpdk.org
> but it may be out of the scope of the DPDK tree.

Good question. I think the scope should be just the DPDK project.

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

At the recent DPDK Userspace event we agreed that we need a body to make 
technical decisions for the project. In Dublin we referred to this as a 
Technical Steering Committee, but that term is often used on other projects to 
describe a body with a more political charter.  To avoid confusion, and clarify 
that the scope of this body for DPDK is purely technical, I propose calling it 
the DPDK Architecture Board.

Justification
-
The role of the Maintainer is to be the gate-keeper for the project, and to 
only accept contributions that are properly implemented, properly reviewed, and 
consistent with the agreed project scope/charter. However, it shouldn't be the 
responsibility of the Maintainer to be the final decision maker (after 
community discussion) on issues affecting the strategic direction of the 
project. Instead, this should be determined by a higher level body that's 
representative of the DPDK community.

Having an Architecture Board will help to provide a clear direction/strategy 
for the project, and help to resolve complex issues which don't reach a 
consensus on the mailing list in a timely manner.

Scope
- 
Issues that are within the scope of the Architecture Board include:
- Project scope/charter. What is and isn't within the scope of the project? 
What happens if somebody wants to upstream a new library/capability and it's 
not clear whether it fits within DPDK or not? As a random example, if somebody 
wanted to upstream a DPDK-enabled TCP/IP stack to dpdk.org, should that be 
accepted or rejected?
- Performance vs functionality considerations. If we need to make a change and 
there's an unavoidable performance impact to doing so (maybe something like 
extending the mbuf again), does that change get accepted or not? In most cases 
you can probably work around situations like this by making them optional, but 
that might not always be possible. If it's not, who decides whether performance 
or functionality is more important?
- Replacing existing functionality versus adding new alternatives. If there's a 
new implementation of an existing DPDK capability that performs better in some 
use cases but worse in others, does that get accepted and replace the existing 
implementation, does it get accepted as an alternative, or does it get rejected?
- Unresolved issues. Provide a decision on issues that don't reach a consensus 
on the mailing list in a timely manner.

Composition
---
For composition of the Architecture Board, I'd propose the following:
- It needs to be kept to a manageable size. I propose limiting it to 5 
initially (it should be an odd number to minimize deadlocks).
- Membership should be based on: number and quality of contributions, technical 
standing in the community, breadth of involvement (involvement in many areas, 
not just a single part of DPDK).
- No single company/organization can have more than 2 members.
- The Architecture Board will elect its own chair, who will have the deciding 
vote in the event of a deadlock.
- The board will review its own composition and co-opt/approve any new members 
on an annual basis.

There are three main options for determining who is on the board:
1. Nomination of representatives by contributing companies. We could allocate a 
number of positions on the board based on the contributions from each company 
and then allow those companies to nominate their representatives. The downsides 
are that many companies contribute but not all can be represented on the board 
so we'd need a way to decide which companies get a seat and which don't, and 
that this focuses the discussion on company contributions rather than 
individuals with the best technical standing
2. Election of representatives. We could poll for candidates and then vote. 
This is likely to take time because we'll need to agree and implement the 
process to support an election.
3. Seed the board with those who have the best technical standing in the 
community. We could determine the initial composition by consensus. I think the 
prime candidates for an Architecture Board will be obvious to most of us.

My preference would be for option 3. Any other opinions or comments on this 
proposal?


Tim

[dpdk-dev] Hyperscan open source release

[O'Driscoll, Tim]

At the recent DPDK Userspace event in Dublin, Mohammad Abdul Awal gave a brief 
talk on the Hyperscan pattern match software. We said at the time that it 
wasn't open sourced yet but it would be soon. It's now available at: 
https://01.org/hyperscan and https://github.com/01org/hyperscan.


Tim

[dpdk-dev] DPDK Logo Release

[O'Driscoll, Tim]

We'd like to announce the release of the new DPDK project logo. Various 
versions of the logo are available at: http://dpdk.org/about. This includes 
horizontal and vertical versions, versions with and without Data Plane 
Development Kit underneath, and versions suitable for a white or black 
background. There's an example dpdk.org page showing use of the logo at: 
http://dpdk.org/777.html.

These logos are available for anybody in the community to use in DPDK-related 
collateral.

The logos are provided by Intel under a Creative Commons 
Attribution-NoDerivatives 4.0 License (CC BY-ND 4.0 - 
http://creativecommons.org/licenses/by-nd/4.0/).


Tim

[dpdk-dev] DPDK.org Community Call - Sept 24 - Discuss Growth, Improvements

[O'Driscoll, Tim]

Thanks to everybody who attended and provided input at last week's meeting. It 
was a good, open discussion, and hopefully is the first step towards 
structuring the DPDK project to facilitate its continued growth.

I've included a summary of the discussion below. Please feel free to provide 
any additional input, or to clarify/correct if I've misrepresented anything 
below.

The key follow up action is to continue this discussion at the Userspace event 
in Dublin next week. We have a discussion topic on this on the Thursday 
afternoon (see https://dpdksummit.com/us/en/userspace2015). Following the 
Userspace event we'll determine what additional calls and/or mailing list 
discussions are required.


Attendees: Alejandro Lucero (Netronome), Andrew Harvey (Cisco), Andrey Chilikin 
(Intel), Aws Ismail (Ciena), Bernard Iremonger (Intel), Bill Fischofer 
(Linaro), Bruce Richardson (Intel), Damjan Marion (Cisco), Daniel Mrzyglod 
(Intel), Dave Barach (Cisco), Dave Hunt (Intel), Dave Neary (Red Hat), Declan 
Doherty (Intel), Ed Warnicke (Cisco), Fan Zhang (Intel), Gary Mussar (Ciena), 
Harry van Haaren (Intel), Jasvinder Singh (Intel), Jianfeng Tan (Intel), Jim St 
Leger (Intel), John Bromhead (Cavium), John McNamara (Intel), Keith Wiles 
(Intel), Margaret Chiosi (AT), Mike Glynn (Intel), Mike Holmes (Linaro), 
Pablo de Lara Guarch (Intel), Pradeep Kathail (Cisco), Prasanth Kannan (), 
Reshma Pattah (Intel),  Roger Melton (Cisco), Santosh Shukla (Linaro), Sergio 
Gonzalez Monroy (Intel), Siobhan Butler (Intel), Thomas Herbert (Red Hat), 
Thomas Monjalon (6WIND), Tim O'Driscoll (Intel), Venky Venkatesan (Intel)

Note that this info was pulled from the GoToMeeting tool, but people joined and 
left at different times during the call so it may not be a complete list.


Purpose: 
1. Structure for growth: Do we have the community practices, policies, and 
procedures in place to allow us to continue to grow on our current trajectory?

2. Gaps Limiting Participation: What gaps do companies who would like to 
participate/contribute to DPDK.org see? What changes would they like to see 
made to improve the project?


Minutes:
The main topics that were discussed were:

Is the project structured correctly to manage continued growth?
- We've seen a steady increase in total contributions and number of 
contributors from one release to the next.
- Some participants felt that decisions seem to be arbitrary and come down to a 
couple of people being vocal on the mailing list. We need to determine a better 
decision making process.
- Some participants felt that DPDK needs to pay more attention to its consumers 
and are not sure that the current structure encourages this.

Several companies have ARM ports and other enhancements to DPDK that have not 
been upstreamed. What's preventing this from happening?
- There are concerns that DPDK is currently very focused on x86 and PCI-based 
devices, and would not be receptive to an ARM port. How do we get a more 
balanced approach? The technical issues can be fixed, but it's not clear 
whether the SoC vendors believe the project structure/governance is sufficient 
to accept these kinds of changes. Several people have heard these concerns 
expressed in private, but they have not be aired in public.
- A concern was expressed that we haven't heard sufficient input from 
Linaro/ARM vendors on this. How do we get more input from them?

Should the project be governed by a single company?
- There were several acknowledgements of the contribution that Thomas Monjalon 
has made to the project, including the fact that he completed the 2.1 release 
while on vacation. There was a concern though that this dependency on a single 
key individual doesn't scale as the project continues to grow.
- Some participants stated that they would have more confidence in the project 
if it wasn't run by a single company. Having a broader governance structure 
would help the project scale and make sure it's independent of any single 
company's business interests. This is largely a perception issue and no patches 
have been rejected so far because they conflict with the business interests of 
community members. A concern was expressed that the resistance seen to 
upstreaming an IPsec sample application may fall into this category in future.
- Discussed the creation of a Technical Steering Committee, which was proposed 
previously on the mailing list. Some expressed the view that this should be 
composed of contributors to the project, others that it should be more balanced 
between contributors and consumers.

Convergence between DPDK and ODP came up a few times. Agreed that the focus of 
this discussion was on governance and that convergence needs to be dealt with 
separately.

Next steps:
- For those attending the Userspace event in Dublin, we have a discussion topic 
on this on the Thursday afternoon (see 
https://dpdksummit.com/us/en/userspace2015). Those who are interested in 
continuing this discussion should 

[dpdk-dev] DPDK 2.2 roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, September 10, 2015 1:44 PM
> To: O'Driscoll, Tim
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK 2.2 roadmap
>
> 2015-09-09 12:56, O'Driscoll, Tim:
> > DCB for i40e :  DCB support will be extended to the i40e and X550
> NICs.
>
> A patch for DCB on X550 is already applied but the release notes part
> was forgotten.
>
> > IPsec Sample App:  A sample application will be provided to show how
> the
> > cryptodev library can be used to implement IPsec. This will be based
> on
> > the NetBSD IPsec implementation.
>
> For each API, it is really interesting to have some unit tests and some
> examples to show how it should be used. However adding an IPsec stack
> looks
> to be beyond the need of an API example. It may be big and difficult to
> maintain when updating DPDK.
> Why not spawn a new project here: http://dpdk.org/browse/ ?

What we're planning is a sample application that shows how hardware and 
software crypto accelerators can be used to accelerate a typical workload, 
which happens to be IPsec. We plan to provide an RFC next week which will give 
further details on what's being proposed. We don't expect maintenance to be a 
problem, but we can discuss that further when the scope has been clarified.

[dpdk-dev] DPDK 2.2 roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, September 9, 2015 9:45 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK 2.2 roadmap
> 
> Hello,
> 
> The new features for the release 2.2 must be first submitted before 2nd
> October.
> They should be integrated before 23rd October.
> 
> In order to ease cooperation and integration, it would be nice to see
> announces or technical details of planned features for 2.2 or 2.3.
> Then the roadmap page will be filled accordingly:
>   http://dpdk.org/dev/roadmap
> Generally speaking, it helps to know what you are working on and what is
> the
> status.

I think it's a great idea to create an overall roadmap for the project for 2.2 
and beyond. To kick this off, below are the features that we're hoping to 
submit for the 2.2 release. You should be seeing RFCs and v1 patch sets for 
these over the next few weeks.

Userspace Ethtool Sample App:  Further enhancements to the userspace ethtool 
implementation that was submitted in 2.1 including: Implement rte_ethtool shim 
layer based on rte_ethdev API, Provide a sample application that 
demonstrates/allows testing of the rte_ethtool API, Implement 
rte_ethtool_get_ringparam/rte_ethtool_set_ringparam, Rework 
rte_eth_dev_get_reg_info() so we can get/set HW registers in a convenient way.

Vector PMD for fm10k:  A vector PMD, similar to the one that currently exists 
for the Intel 10Gbps NICs, will be implemented for fm10k.

DCB for i40e :  DCB support will be extended to the i40e and X550 NICs.

IEEE1588 on X550 & fm10k:  IEEE1588 support will be extended to the X550 and 
fm10k.

IEEE1588 Sample App:  A sample application for an IEEE1588 Client.

Cryptodev Library:  This implements a cryptodev API and PMDs for the Intel 
Quick Assist Technology DH895xxC hardware accelerator and the AES-NI 
multi-buffer software implementation. See 
http://dpdk.org/ml/archives/dev/2015-August/022930.html for further details.

IPsec Sample App:  A sample application will be provided to show how the 
cryptodev library can be used to implement IPsec. This will be based on the 
NetBSD IPsec implementation.

Interrupt Mode for i40e, fm10k & e1000:  Interrupt mode support, which was 
added in the 2.1 release, will be extended to the 140e, fm10k and e1000.

Completion of PCI Hot Plug:  PCI Hot Plug support, which was added in the 2.0 
and 2.1 releases, will be extended to the Xenvirt and Vmxnet3 PMDs.

Increase Number of Next Hops for LPM (IPv4 and IPv6):  The current DPDK 
implementation for LPM for IPv4 and IPv6 limits the number of next hops to 256, 
as the next hop ID is an 8-bit long field. The size of the field will  be 
increased to allow an increased number of next hops.

Performance Thread Sample App:  A sample application will be provided showing 
how different threading models can be used in DPDK. It will be possible to 
configure the application for, and contrast forwarding performance of, 
different threading models including lightweight threads. See 
http://dpdk.org/ml/archives/dev/2015-September/023186.html for further details.

DPDK Keep-Alive:  The purpose is to detect packet processing core failures 
(e.g. infinite loop) and ensure the failure of the core does not result in a 
fault that is not detectable by a management entity.

Vhost Offload Feature Support:  This feature will implement virtio TSO offload 
to help improve performance.

Common Port Statistics:  This feature will extend the exposed NIC statistics, 
improving the method of presentation to make it obvious what their purpose is. 
This functionality is based on the rte_eth_xstats_* extended stats API 
implemented in DPDK 2.1.

NFV Use-cases using Packet Framework (Edge Router):  Enhancements will be made 
to the IP_Pipeline application and the Packet Framework libraries so that they 
can be used to support an Edge Router NFV use case.

Refactor EAL for Non-PCI Devices:  This has been discussed extensively on the 
mailing list. See the RFCs for Refactor eal driver registration code 
(http://dpdk.org/ml/archives/dev/2015-September/023257.html) and Remove pci 
driver from vdevs (http://dpdk.org/ml/archives/dev/2015-August/023016.html).

Vhost Multi-Queue Support:  The vhost-user library will be updated to provide 
multi-queue support in the host similar to the RSS model so that guest driver 
may allocate multiple rx/tx queues which then may be used to load balance 
between cores. See http://dpdk.org/ml/archives/dev/2015-August/022758.html for 
more details.

Virtio Vhost Optimization:  Virtio and vhost performance will be optimized to 
allow efficient high performance packet movement between guest and host.

Config Granularity of RSS for i40e:  All RSS hash and filter configurations for 
IPv4/v6, TCP/UDP, GRE, etc will be implemented for i40e. This includes support 
for QinQ and tunneled packets.

I40e 32-bit GRE Keys:  Both 24 and 32 bit keys for GRE will be supported for 
i40e.

X550 

[dpdk-dev] [PATCH v3] doc: announce abi change for interrupt mode

[O'Driscoll, Tim]

Hi Neil,

There have been a few deprecation notices like this one submitted. Since you 
drove the ABI policy, it would be good to get confirmation from you that these 
are compliant with the policy and that you don't see any issues. Ideally, it 
would be great if you can review and ack them. If you don't have the time, even 
just a general indication that you don't see any problems would be useful.


Thanks,
Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Liu, Yong
> Sent: Thursday, July 30, 2015 6:15 AM
> To: Liang, Cunming; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] doc: announce abi change for
> interrupt mode
> 
> Acked-by: Marvin Liu 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang
> > Sent: Thursday, July 30, 2015 1:05 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v3] doc: announce abi change for interrupt
> mode
> >
> > The patch announces the planned ABI changes for interrupt mode.
> >
> > Signed-off-by: Cunming Liang 
> > ---
> >  v3 change:
> >- reword for CONFIG_RTE_NEXT_ABI
> >
> >  v2 change:
> >- rebase to recent master
> >
> >  doc/guides/rel_notes/deprecation.rst | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 5330d3b..d36d267 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -35,3 +35,8 @@ Deprecation Notices
> >  * The following fields have been deprecated in rte_eth_stats:
> >imissed, ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
> >tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
> > +
> > +* The ABI changes are planned for struct rte_intr_handle, struct
> > rte_eth_conf
> > +  and struct eth_dev_ops to support interrupt mode feature from
> release
> > 2.1.
> > +  Those changes may be enabled in the upcoming release 2.1
> > +  with CONFIG_RTE_NEXT_ABI.
> > --
> > 1.8.1.4

[dpdk-dev] Register for Userspace 2015

[O'Driscoll, Tim]

Those of you who have looked at the website for the event 
(https://dpdksummit.com/us/en/userspace2015) will have seen that we're planning 
to have 3 different types of presentations:

Standard presentation sessions:
- Scheduled for both Thursday and Friday mornings.
- Opportunity to present on a topic in detail.
- ~45 mins - 1 hour in duration, including time for questions.
- Requires preparation of slides.

Discussion/workshop sessions:
- Scheduled for Thursday afternoon
- No presentation, just a discussion amongst people interested in a topic.
- The plan is to run 3 topics in parallel, with people dividing based on the 
topic that they're most interested in.
- Each session will have a facilitator who will moderate the discussion to keep 
things moving.

Lightning Talks:
- Scheduled for Friday afternoon.
- Opportunity to give a quick overview of a topic that may be of interest to 
the community.
- 15 mins duration, including time for questions.
- Little preparation required. You can use a few slides if you wish, use a 
whiteboard, or just talk.

If you want to present, give a lightning talk, or have a suggestion for a topic 
for a workshop/discussion session, please let me know. We plan to finalise and 
publish the agenda by the end of August.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Butler, Siobhan A
> Sent: Friday, July 24, 2015 6:09 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Register for Userspace 2015
> 
> Hi all
> 
> Just a gentle reminder to register your attendance for DPDK Userspace
> 2015 at https://dpdksummit.com/us/en/userspace2015 as places are filling
> up and are strictly limited :)
> 
> Thanks
> Siobhan

[dpdk-dev] [dpdk-announce] DPDK Summit, San Francisco 2015 is open for registration

[O'Driscoll, Tim]

This is just a reminder that on August 17 the DPDK open source community will 
gather in San Francisco for the 2nd annual DPDK Summit.  It's a one day event 
where the community will share some of their developments, applications, and 
usage of DPDK.  The event will include talks from HP, IBM Aspera, Intel, NTT, 
RiftIO, and Sprint.  In addition there will be ample networking opportunities 
including themed tables during lunch to foster discussion and an evening 
reception.

The event is free, and you can register today at https://dpdksummit.com/.


Tim

> From: announce [mailto:announce-bounces at dpdk.org] On Behalf Of Kantak, 
> Pravin
> Sent: Monday, July 6, 2015 6:42 PM
> To: announce at dpdk.org
> Subject: [dpdk-announce] DPDK Summit, San Francisco 2015 is open for 
> registration
> 
> You are invited to DPDK Summit, San Francisco 2015!
>
> Date:??? Monday, August 17, 2015
>
> Time:??? 8:30 AM - 5:30 PM (Summit)
>??5:30 PM - 7:30 PM (Reception)
>
> Location:The Westin St. Francis
>???   335 Powell Street
>???   San Francisco, CA 94102
>
> DPDK Summit, San Francisco 2015 is announced to commence on August 17th. If 
> you are new
> in the community, these events make a great occasion for our DPDK open source 
> community
> to get together face-to-face around the world for a forward looking dialogue.
>
> Based on your feedback last year, we added an evening reception for you all 
> to continue
> your dialogue throughout the day and into the evening over drinks.
>
> Register today at https://dpdksummit.com/
>
> Seating is limited and offered on a first-come basis. Register now to reserve 
> your
> complimentary seat.

> Learn more about DPDK Summit at https://dpdksummit.com/us/en/about?or visit 
> http://dpdk.org/events
>
>
> For more information regarding this event, please contact support at 
> dpdksummit.com.
>
>
>
> Thanks,
> -Pravin

[dpdk-dev] [dpdk-announce] important design choices - statistics - ABI

[O'Driscoll, Tim]

> -Original Message-
> From: announce [mailto:announce-bounces at dpdk.org] On Behalf Of Thomas
> Monjalon
> Sent: Wednesday, June 17, 2015 12:30 AM
> To: announce at dpdk.org
> Subject: [dpdk-announce] important design choices - statistics - ABI
> 
> Hi all,
> 

> During the development of the release 2.0, there was an agreement to
> keep
> ABI compatibility or to bring new ABI while keeping old one during one
> release.
> In case it's not possible to have this transition, the (exceptional)
> break
> should be acknowledged by several developers.
>   http://dpdk.org/doc/guides-2.0/rel_notes/abi.html
> There were some interesting discussions but not a lot of participants:
>   http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus
> =8461
> 
> During the current development cycle for the release 2.1, the ABI
> question
> arises many times in different threads.
> To add the hash key size field, it is proposed to use a struct padding
> gap:
>   http://dpdk.org/ml/archives/dev/2015-June/019386.html
> To support the flow director for VF, there is no proposal yet:
>   http://dpdk.org/ml/archives/dev/2015-June/019343.html
> To add the speed capability, it is proposed to break ABI in the release
> 2.2:
>   http://dpdk.org/ml/archives/dev/2015-June/019225.html
> To support vhost-user multiqueues, it is proposed to break ABI in 2.2:
>   http://dpdk.org/ml/archives/dev/2015-June/019443.html
> To add the interrupt mode, it is proposed to add a build-time option
> CONFIG_RTE_EAL_RX_INTR to switch between compatible and ABI breaking
> binary:
>   http://dpdk.org/ml/archives/dev/2015-June/018947.html
> To add the packet type, there is a proposal to add a build-time option
> CONFIG_RTE_NEXT_ABI common to every ABI breaking features:
>   http://dpdk.org/ml/archives/dev/2015-June/019172.html
> We must also better document how to remove a deprecated ABI:
>   http://dpdk.org/ml/archives/dev/2015-June/019465.html
> The ABI compatibility is a new constraint and we need to better
> understand
> what it means and how to proceed. Even the macros are not yet well
> documented:
>   http://dpdk.org/ml/archives/dev/2015-June/019357.html
> 
> Thanks for your attention and your participation in these important
> choices.

There's been some good discussion on the ABI policy in various responses to 
this email. I think we now need to reach a conclusion on how we're going to 
proceed for the 2.1 release. Then, we can have further discussion on the use of 
versioning or other methods for avoiding the problem in future.

For the 2.1 release, I think we should agree to make patches that change the 
ABI controllable via a compile-time option. I like Olivier's proposal on using 
a single option (CONFIG_RTE_NEXT_ABI) to control all of these changes instead 
of a separate option per patch set (see 
http://dpdk.org/ml/archives/dev/2015-June/019147.html), so I think we should 
rework the affected patch sets to use that approach for 2.1.


Tim

[dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Andrew Harvey (agh)
> Sent: Wednesday, June 3, 2015 3:10 AM
> To: Thomas Monjalon; Wang, Liang-min
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
> ethtool-alike APIs
> 
> I believe that their is value in this interface for software stacks not
> based on Linux being moved toward DPDK that need simple operations like
> getting the mac address.  Some of these stacks have a dearth of
> resources
> available and dedicating a core/thread to KNI to get/set a mac address
> is considered excessive. There are also issues with 32/64 bit kernel
> integration
> using KNI.  If the ethtool interface is not the correct interface then
> please help me
> understand what should/could have been used. If ethtool is considered
> 'old
> and clunky?
> Stephen's and your input would be valuable in designing another
> interface
> with
> similar properties.  The use-case is pretty simple and there is no plans
> for moving
> anything back into the kernel on the contrary its the complete opposite.
> 
> < Andy

Stephen, Thomas: I think it was the two of you that originally questioned the 
justification for including this change. Now that Andy and Dave Harton have 
clarified, does this resolve your concerns or do you still have questions? I 
just want to make sure that we reach a timely conclusion on this.


Tim

> 
> 
> On 6/2/15, 1:37 PM, "Thomas Monjalon"  wrote:
> 
> >I have the feeling we are not progressing in this discussion.
> >Please bring new explanations or I'll give up.
> >David Harton already acked it so maybe he could explain why it is
> useful.
> >
> >Comments below
> >
> >2015-06-02 17:06, Wang, Liang-min:
> >> >2015-06-02 15:47, Wang, Liang-min:
> >> >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> >> >> > >>I'm curious to understand how renaming rte_eth_dev_set_mtu()
> to
> >> >> > >>rte_ethtool_net_change_mtu() will help anyone.
> >> >> >>
> >> >> >> As described, this interface is designed to provide API closely
> >>to kernel space ethtool ops and net_device_op.
> >> >>
> >> >> >But the application still needs to adapt the code to call rte_*
> >>functions.
> >> >> >So changing to rte_ethtool_net_change_mtu is equivalent to change
> >>to the existing rte_eth_dev_set_mtu. I don't see the benefit.
> >> >>
> >> >> The benefit is single interface for users to access. Instead of
> >>looking into two different interfaces (ethtool, ether).
> >> >
> >> >Sorry it doesn't help to understand.
> >> >Today, there is an ethdev API. Why adding an ethtool-like API would
> >>help?
> >>
> >> Need to understand your specific concern. Do you oppose introducing
> new
> >>API to support ethtool ops and net_device_ops?
> >
> >They are not ethtool/netdev ops but fake ones.
> >In linux:
> > int dev_set_mtu(struct net_device *dev, int new_mtu)
> >In dpdk:
> > int rte_ethtool_net_change_mtu(uint8_t port_id, int mtu);
> >So yes, I'm opposed to add an API which is neither ethdev, neither
> >ethtool.
> >But I may be missing an obvious justification.
> >
> >> Or your concern is on the implementation. If that's latter.
> >> Do you oppose adding a new library to implement ethtool ops and
> >>net_device_ops?
> >
> >Already answered above
> >
> >> If so, are you satisfied with my previous answer on avoiding
> >>polluting ethdev APIs?
> >> If not, do you suggest integrating ethtool APIs into ethdev
> API?
> >
> >No, it's better as a separate library.
> >
> >> If not, is your concern on the implementation of common
> >>functionality between ethtool and ethdev APIs?
> >> If so, as explained, it is designed to provide a unified
> >>interface to assist users to migrate from kernel ethtool/net-device-op
> >>API to DPDK
> >
> >Do you mean it would help migrating some code from kernel space to
> dpdk?
> >How it would help since the functions and data are different from the
> >kernel ones?
> >
> >> BTW, as my reply to Steve's comment, more ops are on their way. This
> >>patch is to open up the interface.
> >
> >Currently they are only some one-liners plus ethtool_drvinfo formatting
> >so there is no real benefit.
> >Why not wait to have more ops implemented?
> >

[dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in rte_mbuf

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Monday, June 1, 2015 9:15 AM
> To: Zhang, Helin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in
> rte_mbuf
> 
> Hi Helin,
> 
> +CC Neil
> 
> On 06/01/2015 09:33 AM, Helin Zhang wrote:
> > In order to unify the packet type, the field of 'packet_type' in
> > 'struct rte_mbuf' needs to be extended from 16 to 32 bits.
> > Accordingly, some fields in 'struct rte_mbuf' are re-organized to
> > support this change for Vector PMD. As 'struct rte_kni_mbuf' for
> > KNI should be right mapped to 'struct rte_mbuf', it should be
> > modified accordingly. In addition, Vector PMD of ixgbe is disabled
> > by default, as 'struct rte_mbuf' changed.
> > To avoid breaking ABI compatibility, all the changes would be
> > enabled by RTE_UNIFIED_PKT_TYPE, which is disabled by default.
> 
> What are the plans for this compile-time option in the future?
> 
> I wonder what are the benefits of having this option in terms
> of ABI compatibility: when it is disabled, it is ABI-compatible but
> the packet-type feature is not present, and when it is enabled we
> have the feature but it breaks the compatibility.
> 
> In my opinion, the v5 is preferable: for this kind of features, I
> don't see how the ABI can be preserved, and I think packet-type
> won't be the only feature that will modify the mbuf structure. I think
> the process described here should be applied:
> http://dpdk.org/browse/dpdk/tree/doc/guides/rel_notes/abi.rst
> 
> (starting from "Some ABI changes may be too significant to reasonably
> maintain multiple versions of").
> 
> 
> Regards,
> Olivier
> 

This is just like the change that Steve (Cunming) Liang submitted for Interrupt 
Mode. We have the same problem in both cases: we want to find a way to get the 
features included, but need to comply with our ABI policy. So, in both cases, 
the proposal is to add a config option to enable the change by default, so we 
maintain backward compatibility. Users that want these changes, and are willing 
to accept the associated ABI change, have to specifically enable them.

We can note in the Deprecation Notices in the Release Notes for 2.1 that these 
config options will be removed in 2.2. The features will then be enabled by 
default.

This seems like a good compromise which allows us to get these changes into 2.1 
but avoids breaking the ABI policy.


Tim

> 
> 
> >
> > Signed-off-by: Helin Zhang 
> > Signed-off-by: Cunming Liang 
> > ---
> >  config/common_linuxapp |  2 +-
> >  .../linuxapp/eal/include/exec-env/rte_kni_common.h |  6 ++
> >  lib/librte_mbuf/rte_mbuf.h | 23
> ++
> >  3 files changed, 30 insertions(+), 1 deletion(-)
> >
> > v2 changes:
> > * Enlarged the packet_type field from 16 bits to 32 bits.
> > * Redefined the packet type sub-fields.
> > * Updated the 'struct rte_kni_mbuf' for KNI according to the mbuf
> changes.
> >
> > v3 changes:
> > * Put the mbuf layout changes into a single patch.
> > * Disabled vector ixgbe PMD by default, as mbuf layout changed.
> >
> > v5 changes:
> > * Re-worded the commit logs.
> >
> > v6 changes:
> > * Disabled the code changes for unified packet type by default, to
> >   avoid breaking ABI compatibility.
> >
> > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > index 0078dc9..6b067c7 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -167,7 +167,7 @@ CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
> >  CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
> >  CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
> >  CONFIG_RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC=y
> > -CONFIG_RTE_IXGBE_INC_VECTOR=y
> > +CONFIG_RTE_IXGBE_INC_VECTOR=n
> >  CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
> >
> >  #
> > diff --git a/lib/librte_eal/linuxapp/eal/include/exec-
> env/rte_kni_common.h b/lib/librte_eal/linuxapp/eal/include/exec-
> env/rte_kni_common.h
> > index 1e55c2d..7a2abbb 100644
> > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > @@ -117,9 +117,15 @@ struct rte_kni_mbuf {
> > uint16_t data_off;  /**< Start address of data in segment
> buffer. */
> > char pad1[4];
> > uint64_t ol_flags;  /**< Offload features. */
> > +#ifdef RTE_UNIFIED_PKT_TYPE
> > +   char pad2[4];
> > +   uint32_t pkt_len;   /**< Total pkt len: sum of all segment
> data_len. */
> > +   uint16_t data_len;  /**< Amount of data in segment buffer. */
> > +#else
> > char pad2[2];
> > uint16_t data_len;  /**< Amount of data in segment buffer. */
> > uint32_t pkt_len;   /**< Total pkt len: sum of all segment
> data_len. */
> > +#endif
> >
> > /* fields on second cache line */
> > char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
> > diff --git a/lib/librte_mbuf/rte_mbuf.h 

[dpdk-dev] Technical Steering Committee (TSC)

[O'Driscoll, Tim]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> 
> On Tue, May 19, 2015 at 05:45:05PM +0200, Thomas Monjalon wrote:
> > 2015-05-19 11:34, Neil Horman:
> > > On Tue, May 19, 2015 at 07:43:14AM -0700, Stephen Hemminger wrote:
> > > > > Composition of the TSC should reflect contributions to the
> project, but be
> > > > > balanced so that no single party has an undue influence. It
> should also be
> > > > > kept to a manageable size(maybe 7?).
> > > > >
> > > > > The TSC should elect its own chair, who would have the deciding
> vote in
> > > > > the event that the TSC was deadlocked. Once in place, the TSC
> should
> > > > > approve any new members.
> > > > >
> > > > > Specific details on membership can be discussed and agreed
> later, if we
> > > > > agree on the creation of a TSC.
> > > >
> > > > TSC should be limited to those individuals and companies that have
> > > > contributed in a non-trivial way to the DPDK distributed code
> base.
> > > > It should not be a users group, or place for network vendors who
> take but
> > > > never give back.
> > > >
> > > +1
> > >
> > > It should also endavour to only act as a fallback body for any
> issues commonly
> > > handled by the development communtiy (patch acceptance/review, etc)
> >
> > I agree that it should be a fallback.
> > And I'm wondering how useful it would be: have we ever known such
> discussion or
> > conflict without finding a solution or a consensus?
> Well, I suppose the jury is still out on that, since there are ongoing
> problems,
> in the form of patch latency, and such.  But for the most part, no,
> problems
> tend to reach consensus resolution IMO

It's true that there aren't many obvious examples, although as Neil points out 
there are still some things that are ongoing. One issue that springs to mind 
where we didn't reach consensus was inclusion of ABI Versioning in 1.8. It was 
subsequently included in 2.0, but there were people who believed it should have 
been in 1.8.

The other issue with having to reach consensus on everything is that it tends 
to a lowest common denominator approach, and can slow things down. There are 
times where a clear decision and then everybody moving forward is preferable.

> > By the way, is there a TSC in Linux netdev?
> >
> No, but there are TSC for many projects, including Openshift,
> freedesktop.org,
> etc.
> 
> Neil

[dpdk-dev] dev@DPDK Hackathon Proposal

[O'Driscoll, Tim]

There wasn't any public response to this but we did discuss it with several 
people separately who all thought it was a good idea. Therefore, we've decided 
to go ahead with it. Siobhan is working on the plan now and should be in a 
position to make a formal announcement in a few weeks.

In the meantime, I wanted to let people know that this is going ahead so that 
you can:
a) Save the date. October 8th/9th, immediately after the European LinuxCon, in 
Dublin Ireland.
b) Think about topics that you'd like to see covered. We'll solicit for inputs 
when the formal announcement is made, but it's good for people to begin 
thinking about this now.

We'd like this to be quite an interactive event with a lot of discussion rather 
than just presentations. We plan to have many of our key DPDK developers there, 
so it will be a great opportunity to network, discuss the technical challenges 
that you're facing and help to build a stronger DPDK community. 


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Butler, Siobhan A
> Sent: Tuesday, March 31, 2015 7:19 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] dev at DPDK Hackathon Proposal
> 
> Hi all,
> 
> As a community we have virtually come together from all over the globe,
> developing now our third successful open source DPDK version with DPDK
> r2.0 about to release.
> It is astounding to comprehend the commitment and enthusiasm you have
> all shared to bring DPDK to this point.
> With growing the community of developers in mind, and strengthening the
> networks and virtual collaborations that have come about,
> I propose that we hold the first dev at DPDK Developer Hackathon this year.
> 
> Many people will be travelling to Dublin, Ireland for LinuxCon and
> CloudOpen October (5th-7th).
> I propose that we hold a hands on 2 day hackathon Thursday October 8th
> and Friday October 9th to coincide with this offering, in Dublin.
> From a community perspective is a great opportunity to bring together
> the people that make DPDK happen - the developers.
> From a developer perspective it is a great opportunity to be part of the
> first gathering, meet some new people, learn something new
> and have a lot of fun on the way.
> 
> At this point the agenda is open - so if you see merit in this proposal
> please share your interest here so that we can gauge attendance
> and gather ideas of what people would like the format to be.
> 
> Thanks,
> Siobhan
> 

[dpdk-dev] Technical Steering Committee (TSC)

[O'Driscoll, Tim]

At Tuesday's Beyond DPDK 2.0 call, one topic we discussed was decision making 
and whether we need a Technical Steering Committee (TSC). As a follow-up to 
that discussion, I'd like to propose that we create a TSC for DPDK to guide the 
long-term strategic direction of the project.


Justification
-

The role of the Maintainer is to be the gate-keeper for the project, and to 
only accept contributions that are properly implemented, properly reviewed, and 
consistent with the agreed project scope/charter. However, it shouldn't be the 
responsibility of the Maintainer to be the final decision maker (after 
community discussion) on issues affecting the strategic direction of the 
project. Instead, this should be determined by a higher level body that's 
representative of the DPDK community.

Having a TSC should help to provide a clear direction/strategy for the project, 
and help to resolve complex issues which don't reach a consensus on the mailing 
list in a timely manner.

There were arguments at the call that a TSC is not required. The alternative 
view though is why would we not put one in place? The TSC could review its own 
progress after 6 months, and if the members don't consider it to be productive, 
then it could be disbanded. I see little effort and zero risk in trying this, 
with the potential gain of a clearer decision making process and a better 
defined project strategy. 


Scope
- 

Issues the TSC should consider should include:
- Project scope/charter. What is and isn't within the scope of the project? 
What happens if somebody wants to upstream a new library/capability and it's 
not clear whether it fits within DPDK or not? As a random example, if somebody 
wanted to upstream a DPDK-enabled TCP/IP stack to dpdk.org, should that be 
accepted or rejected?
- Performance vs functionality considerations. If we need to make a change and 
there's an unavoidable performance impact to doing so (maybe something like 
extending the mbuf again), does that change get accepted or not? In most cases 
you can probably work around situations like this by making them optional, but 
that might not always be possible. If it's not, who decides whether performance 
or functionality is more important?
- Replacing existing functionality versus adding new alternatives. An example 
of this might be Cuckoo Hash. Does that replace the existing hash 
implementation, or should it be provided as an alternative? Who decides this? 
That could be more of an operational issue, but it's borderline.
- Competitive Positioning. Monitor the competitive landscape and determine any 
impacts to future DPDK strategy. 
- Unresolved issues. Provide a decision on issues that don't reach a consensus 
on the mailing list in a timely manner.


Composition
---

Composition of the TSC should reflect contributions to the project, but be 
balanced so that no single party has an undue influence. It should also be kept 
to a manageable size(maybe 7?).

The TSC should elect its own chair, who would have the deciding vote in the 
event that the TSC was deadlocked. Once in place, the TSC should approve any 
new members.

Specific details on membership can be discussed and agreed later, if we agree 
on the creation of a TSC.

[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0

[O'Driscoll, Tim]

Some great input Dave. We discussed a number of issues yesterday which, while 
related, should probably be treated separately for clarity. For each of these, 
I think we need to start with a clear problem statement and a concrete proposal 
for change.

I've added some further comments on the specific items below.

> From: Dave Neary [mailto:dneary at redhat.com]
> 
> Thanks for the notes Tim!
> 
> I had intended to participate, but didn't realise that there was a
> conflict with an OPNFV call at the same time, and a calendaring snafu.
> 
> In the interests of having some more focussed discussion, I have some
> questions on the notes to get beyond passive voice. I think it will be
> useful to have concrete proposals and understand the positions of
> various entities participating in the project (both individuals and
> companies).
> 
> On 05/13/2015 07:19 AM, O'Driscoll, Tim wrote:
> > Thanks to all who attended and contributed to yesterday's discussion.
> For the benefit of those who couldn't attend, here's a brief summary of
> what was covered. Please feel free to point out any errors or omissions.
> >
> > Decision Making
> > - There was a discussion on whether we need a Technical Steering
> Committee or similar decision-making forum. The scope would be to make
> long-term, strategic decisions and to provide a resolution for issues
> that do not reach a consensus on the mailing list.
> > - Some felt that this was a good idea and would help to reach a timely
> conclusion on contentious issues. Others felt that these issues should
> be resolved on the mailing list and/or by the Maintainer.
> 
> In this case, the problem statement could be that it's unclear how items
> can be proposed for inclusion in future releases, and how decisions on
> inclusion are made once proposals are made. Is that correct?
> 
> I am a big fan of transparency in the decision making processes of a
> project. The Linux decision process might be described as: "Subsystem
> owners are kings of their space, but if there is a lack of consensus,
> Linus decides". That works because people trust Linus to be an unbiased
> arbitor of what is best for Linux.
> 
> What would the equivalent de facto decision making process for DPDK be?
> And does it need changing? In the interests of clarity, my understanding
> is that "the Maintainer" in the note above is Thomas Monjalon - can I
> just confirm that this is true and understood by all?

Yes, the Maintainer is Thomas. We do have the concept of separate Maintainers 
for each library (documented in the MAINTAINERS file), but Thomas is the 
overall Maintainer.

As a follow-on to yesterday's call, I'm going to start a separate thread 
specifically on decision making and the role of a TSC.

> > Github
> > - There was some discussion on the merits of github. As with the
> mailing list discussion on this, some were in favour and some against.
> > - Nothing is stopping people using github today and then submitting
> pull requests.
> 
> My feeling is that the tools discussion belies something deeper - it
> could be "reviewing patches and getting a list of unreviewed patches is
> hard", it could be "patches are not reviewed quickly enough", it could
> be "there is no way to tell once a patch has been reviewed what, if any,
> remediation is needed for the patch to be committed". I would like to
> get some feeling on what people see as the underlying fundamental issue
> which the tools change might address.
> 
> Can someone deeply involved in the project have a go at defining a patch
> review workflow problem statement, please?

+1 Any volunteers?

> > DPDK Industry Representation
> > - At the moment, we don't have any project-level DPDK entity or budget
> that would ensure DPDK representation at relevant events. It's left to
> individual contributors to do this.
> >
> > Independent Ownership
> > - It was suggested that it would be better to have independent
> community ownership of the DPDK project.
> > - The argument against this is that the ownership of the
> infrastructure (website, git repo) is not important and can be easily
> cloned if required.
> 
> Were there any concrete proposals or requirements laid out in the call?
> 
> From my point of view, there are a few things which are important here:
>  - Community ownership of the DPDK trademark
>  - The ability to pool resources and enter into contracts for things
> like marketing, developer event organisation, ordering swag
>  - The perception of a level playing field
>  - A framework for commercial entities to indicate their support for
> (and intention to participate in) the project
> 
> The key word here is perceptio

[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0

[O'Driscoll, Tim]

Thanks to all who attended and contributed to yesterday's discussion. For the 
benefit of those who couldn't attend, here's a brief summary of what was 
covered. Please feel free to point out any errors or omissions.

Decision Making
- There was a discussion on whether we need a Technical Steering Committee or 
similar decision-making forum. The scope would be to make long-term, strategic 
decisions and to provide a resolution for issues that do not reach a consensus 
on the mailing list.
- Some felt that this was a good idea and would help to reach a timely 
conclusion on contentious issues. Others felt that these issues should be 
resolved on the mailing list and/or by the Maintainer.

Github
- There was some discussion on the merits of github. As with the mailing list 
discussion on this, some were in favour and some against.
- Nothing is stopping people using github today and then submitting pull 
requests. 

DPDK Industry Representation
- At the moment, we don't have any project-level DPDK entity or budget that 
would ensure DPDK representation at relevant events. It's left to individual 
contributors to do this.

Independent Ownership
- It was suggested that it would be better to have independent community 
ownership of the DPDK project.
- The argument against this is that the ownership of the infrastructure 
(website, git repo) is not important and can be easily cloned if required.

Next Steps
- The conclusion was to have further discussion on the mailing list, and 
possibly schedule a follow-up call in 2-3 weeks.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Monday, May 11, 2015 4:35 PM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK Community Call - Beyond DPDK 2.0
> 
> This is just a reminder that this call is on tomorrow, at the following
> times, which is just under 24 hours from now.
> 
> Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour
> San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00
> AM PDT UTC-7 hours
> Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST
> UTC-7 hours
> Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM
> EDT UTC-4 hours
> New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT
> UTC-4 hours
> Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT
> UTC-4 hours
> London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM
> BST UTC+1 hour
> Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours
> Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours
> Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours
> New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST
> UTC+5:30 hours
> Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at
> 11:00:00 PM CST
> UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00
> 
> 
> It would be good to have as much representation as possible from DPDK
> contributors and users, so that the discussion reflects the views and
> needs of the community.
> 
> 
> Tim
> 
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> >
> > > From: Dave Neary [mailto:dneary at redhat.com]
> > >
> > > When were you thinking of having the call?
> >
> > I put the day and time at the end of the email, but it probably should
> > have been at the start! Apologies that this wasn't clear.
> >
> > Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour
> > San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00
> > AM PDT UTC-7 hours
> > Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST
> > UTC-7 hours
> > Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM
> > EDT UTC-4 hours
> > New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM
> EDT
> > UTC-4 hours
> > Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT
> > UTC-4 hours
> > London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00
> PM
> > BST UTC+1 hour
> > Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours
> > Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3
> hours
> > Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours
> > New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST
> > UTC+5:30 hours
> > Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at
> > 11:00:00 PM CST
> > UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00
> >
> > > It's not been explicit, but can

[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0

[O'Driscoll, Tim]

This is just a reminder that this call is on tomorrow, at the following times, 
which is just under 24 hours from now.

Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour
San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00 AM PDT 
UTC-7 hours
Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST UTC-7 hours
Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM EDT 
UTC-4 hours
New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 
hours
Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 hours
London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM BST 
UTC+1 hour
Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours
Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours
Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours
New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST UTC+5:30 
hours
Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at 11:00:00 PM 
CST
UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00


It would be good to have as much representation as possible from DPDK 
contributors and users, so that the discussion reflects the views and needs of 
the community.


Tim

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> 
> > From: Dave Neary [mailto:dneary at redhat.com]
> >
> > When were you thinking of having the call?
> 
> I put the day and time at the end of the email, but it probably should
> have been at the start! Apologies that this wasn't clear.
> 
> Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour
> San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00
> AM PDT UTC-7 hours
> Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST
> UTC-7 hours
> Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM
> EDT UTC-4 hours
> New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT
> UTC-4 hours
> Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT
> UTC-4 hours
> London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM
> BST UTC+1 hour
> Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours
> Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours
> Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours
> New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST
> UTC+5:30 hours
> Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at
> 11:00:00 PM CST
> UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00
> 
> > It's not been explicit, but can I assume that this call will also be
> > promoted among potential supporters of the project who may not be on
> > this list? I would be interested to get the perspective from the
> people
> > who are perhaps not developers who decide whether their organization
> > engages strategically with a project or not.
> 
> I think this is a great idea. Anybody should feel free to pass this on
> to other interested parties. If we have more contributors to the
> discussion then the output should be more representative of current and
> future community needs.
> 
> 
> Tim

[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0

[O'Driscoll, Tim]

> From: Dave Neary [mailto:dneary at redhat.com]
> 
> When were you thinking of having the call?

I put the day and time at the end of the email, but it probably should have 
been at the start! Apologies that this wasn't clear.

Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour
San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00 AM PDT 
UTC-7 hours
Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST UTC-7 hours
Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM EDT 
UTC-4 hours
New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 
hours
Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 hours
London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM BST 
UTC+1 hour
Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours
Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours
Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours
New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST UTC+5:30 
hours
Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at 11:00:00 PM 
CST
UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00

> It's not been explicit, but can I assume that this call will also be
> promoted among potential supporters of the project who may not be on
> this list? I would be interested to get the perspective from the people
> who are perhaps not developers who decide whether their organization
> engages strategically with a project or not.

I think this is a great idea. Anybody should feel free to pass this on to other 
interested parties. If we have more contributors to the discussion then the 
output should be more representative of current and future community needs.


Tim

[dpdk-dev] DPDK Community Call - Beyond DPDK 2.0

[O'Driscoll, Tim]

There's been a good discussion on the mailing list on the Beyond DPDK 2.0 
thread. To supplement this, we'd like to have a community call for people to 
air their views, and to help progress things towards a conclusion. It'll be an 
open format, so people can bring up whatever issues they want, but some topics 
for discussion might include:
- Decision-making process. What do we do if issues don't reach a conclusion on 
the mailing list? Does stalemate just mean no change, or do we need some other 
mechanism to decide? A good example of an issue that may not reach a clear 
conclusion is the proposal move to github, where some seem to be in favour and 
others against.
- How do we encourage more contributors to DPDK?
- What tool/process improvements do we need to make? Further discussion of 
github is one obvious example.

GoToMeeting Details:
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/556212525

You can also dial in using your phone.
Ireland +353 (0) 19 030 010

Access Code: 556-212-525

More phone numbers
United States (Long distance): +1 (646) 749-3129
Australia (Long distance): +61 2 8355 1020
Austria (Long distance): +43 (0) 7 2088 1047
Belgium (Long distance): +32 (0) 28 08 4368
Canada (Long distance): +1 (647) 497-9353
Denmark (Long distance): +45 (0) 69 91 89 28
Finland (Long distance): +358 (0) 942 59 7850
France (Long distance): +33 (0) 170 950 594
Germany (Long distance): +49 (0) 692 5736 7317
Italy (Long distance): +39 0 247 92 13 01
Netherlands (Long distance): +31 (0) 208 080 219
New Zealand (Long distance): +64 (0) 9 280 6302
Norway (Long distance): +47 75 80 32 07
Spain (Long distance): +34 911 82 9906
Sweden (Long distance): +46 (0) 852 500 186
Switzerland (Long distance): +41 (0) 435 0167 13
United Kingdom (Long distance): +44 (0) 330 221 0088

Here's the time in a variety of time zones:
Dublin (Ireland) - Tuesday, May 12, 2015 at 4:00:00 PM IST UTC+1 hour
San Francisco (U.S.A. - California) - Tuesday, May 12, 2015 at 8:00:00 AM PDT 
UTC-7 hours
Phoenix (U.S.A. - Arizona) - Tuesday, May 12, 2015 at 8:00:00 AM MST UTC-7 hours
Boston (U.S.A. - Massachusetts) - Tuesday, May 12, 2015 at 11:00:00 AM EDT 
UTC-4 hours
New York (U.S.A. - New York) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 
hours
Ottawa (Canada - Ontario) - Tuesday, May 12, 2015 at 11:00:00 AM EDT UTC-4 hours
London (United Kingdom - England) - Tuesday, May 12, 2015 at 4:00:00 PM BST 
UTC+1 hour
Paris (France) - Tuesday, May 12, 2015 at 5:00:00 PM CEST UTC+2 hours
Tel Aviv (Israel) - Tuesday, May 12, 2015 at 6:00:00 PM IDT UTC+3 hours
Moscow (Russia) - Tuesday, May 12, 2015 at 6:00:00 PM MSK UTC+3 hours
New Delhi (India - Delhi) - Tuesday, May 12, 2015 at 8:30:00 PM IST UTC+5:30 
hours
Shanghai (China - Shanghai Municipality) - Tuesday, May 12, 2015 at 11:00:00 PM 
CST
UTC+8 hours Corresponding UTC (GMT) Tuesday, May 12, 2015 at 15:00:00

[dpdk-dev] Beyond DPDK 2.0

[O'Driscoll, Tim]

> From: lukego at gmail.com [mailto:lukego at gmail.com] On Behalf Of Luke 
> Gorrie
>
> > On 16 April 2015 at 12:38, O'Driscoll, Tim <tim.o'driscoll at intel.com> 
> > wrote:
> > Following the launch of DPDK by Intel as an internal development project, 
> > the launch of dpdk.org by
> > 6WIND in 2013, and the first DPDK RPM packages for Fedora in 2014, 6WIND, 
> > Red Hat and Intel would
> > like to prepare for future releases after DPDK 2.0 by starting a discussion 
> > on its evolution. Anyone
> > is welcome to join this initiative.
>
> Thank you for the open invitation.
> 
> I have a couple of questions about the long term of DPDK:
> 
> 1. How will DPDK manage overlap with other project over time?
> 
> In some ways DPDK is growing more overlap with other projects e.g. 
> forking/rewriting functionality from
> Linux (e.g. ixgbe), FreeBSD (e.g. Broadcom PMD), GLIBC (e.g. memcpy).
> 
> In other ways DPDK is delegating functionality to external systems instead 
> e.g. the bifurcated driver
> (delegate to kernel) and Mellanox PMD (delegate to vendor shared library).
> 
> How is this going to play out over the long term? And is there an existential 
> risk that it will end up
> being easier to port the good bits of DPDK into the kernel than the rest of 
> the good bits of the kernel
> into DPDK?

Good question. I don't have a good answer to this, but it is something we will 
need to consider. Perhaps others have opinions?

> 2. How will DPDK users justify contributing to DPDK upstream?
> 
> Engineers in network equipment vendors want to contribute to open source, but 
> what is the incentive for
> the companies to support this? This would be easy if DPDK were GPL'd (they 
> are compelled) or if everybody
> were dynamically linking with the upstream libdpdk (can't have private 
> patches). However, in a world where
> DPDK is BSD-licensed and statically linked, is it not both cheaper and 
> competitively advantageous to keep
> fixes and optimizations in house?
> 
> Today the community is benefiting immensely from the contributions of 
> companies like 6WIND and Brocade,
> but I wonder if this going to be the exception or the rule.

That's another good question. Expanding the community and soliciting more 
contributions is one of the reasons for initiating this discussion.

At first glance, it can seem cheaper and competitively advantageous for people 
to keep DPDK enhancements/optimisations in house. However, that's not 
necessarily the case. There is an advantage in upstreaming these changes 
because firstly others in the community may contribute further enhancements, 
and also because it makes upgrading to new DPDK versions easier because those 
enhancements will be a core part of DPDK rather than having to be ported 
separately to new DPDK versions.

> That's all from me. Thanks for listening :-).

Thanks for contributing your views.

[dpdk-dev] DPDK Community Call - Software QoS

[O'driscoll, Tim]

This was meant to be sent as a calendar invite, so the time would automatically 
convert to your local time zone. That didn't seem to work though. I'm not sure 
if that's just the way the mailing list works, or if it's an outlook config 
error on my side.

Anyway, here's the date and time in a variety of time zones:

Dublin (Ireland) - Tuesday, April 21, 2015 at 4:00:00 PM  IST  UTC+1 hour 
San Francisco (U.S.A. - California) - Tuesday, April 21, 2015 at 8:00:00 AM  
PDT  UTC-7 hours
Phoenix (U.S.A. - Arizona) - Tuesday, April 21, 2015 at 8:00:00 AM  MST  UTC-7 
hours
Boston (U.S.A. - Massachusetts) - Tuesday, April 21, 2015 at 11:00:00 AM EDT  
UTC-4 hours
New York (U.S.A. - New York) - Tuesday, April 21, 2015 at 11:00:00 AM EDT  
UTC-4 hours
Ottawa (Canada - Ontario) - Tuesday, April 21, 2015 at 11:00:00 AM EDT  UTC-4 
hours
London (United Kingdom - England) - Tuesday, April 21, 2015 at 4:00:00 PM  BST  
UTC+1 hour 
Paris (France) - Tuesday, April 21, 2015 at 5:00:00 PM  CEST UTC+2 hours
Tel Aviv (Israel) - Tuesday, April 21, 2015 at 6:00:00 PM  IDT  UTC+3 hours
Moscow (Russia) - Tuesday, April 21, 2015 at 6:00:00 PM  MSK  UTC+3 hours
New Delhi (India - Delhi) - Tuesday, April 21, 2015 at 8:30:00 PM  IST  
UTC+5:30 hours 
Beijing (China - Beijing Municipality) - Tuesday, April 21, 2015 at 11:00:00 PM 
CST  UTC+8 hours
Corresponding UTC (GMT) - Tuesday, April 21, 2015 at 15:00:00

Apologies for any confusion.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim
> Sent: Wednesday, April 1, 2015 4:41 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK Community Call - Software QoS
> 
> Agenda:
> - Software Quality of Service (Cristian Dumitrescu)
> 
> 
> Tue, Apr 21, 4:00-5:30 PM GMT Daylight Time
> 
> Please join my meeting from your computer, tablet or smartphone.
> https://global.gotomeeting.com/join/293233645
> 
> You can also dial in using your phone.
> Ireland : +353 (0) 15 290 180
> United States : +1 (312) 757-3126
> Australia : +61 2 9087 3604
> Austria : +43 (0) 7 2088 0034
> Belgium : +32 (0) 28 08 9321
> Canada : +1 (647) 497-9350
> Denmark : +45 (0) 69 91 80 05
> Finland : +358 (0) 931 58 1746
> France : +33 (0) 182 880 780
> Germany : +49 (0) 692 5736 7211
> Italy : +39 0 699 26 68 58
> Netherlands : +31 (0) 208 908 267
> New Zealand : +64 (0) 9 442 7358
> Norway : +47 21 54 32 44
> Spain : +34 911 23 0850
> Sweden : +46 (0) 853 527 835
> Switzerland : +41 (0) 435 0006 96
> United Kingdom : +44 (0) 20 3713 5028
> 
> Access Code: 293-233-645
> Audio PIN: Shown after joining the meeting
> 

[dpdk-dev] Patches outstanding

[O'driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, February 19, 2015 1:47 PM
> To: Neil Horman
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: Re: [dpdk-dev] Patches outstanding
> 
> 2015-02-19 08:08, Neil Horman:
> > On Tue, Feb 17, 2015 at 10:35:07AM -0500, Stephen Hemminger wrote:
> > > There are currently 1039 patches outstanding on DPDK.
> > > What is the schedule for getting these merged or resolved?
> > > I don't think it would be reasonable to declare 2.0 as done
> > > until the patch backlog is 0!
> > >
> >
> > I think the subtrees were supposed to start biting into this, but I don't 
> > see
> > them getting used yet.
> 
> Yes
> Actually the main problem is still on reviews.
> There are more good reviews in this cycle.
> But some patchset are not reviewed and some others are acked
> without being carefully reviewed.

Progress on reviews has been a little slow on our side. One of the reasons for 
this is that our PRC team are on their new year holidays at the moment, so 
we're a little short staffed. They return to the office in the middle of next 
week, after which we'll be back to full strength.

We do agree with Thomas on the need for thorough reviews. We're working on 
this, so you should see more reviews/acknowledgements soon.


Tim

[dpdk-dev] DPDK Community Call, Monday 2nd February, 17:00 GMT

[O'driscoll, Tim]

> From: O'driscoll, Tim
> 
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> >
> > On Tue, 20 Jan 2015 15:21:40 +0000
> > "O'driscoll, Tim" <tim.o'driscoll at intel.com> wrote:
> >
> > > We had our last community call in December, and then took a break over
> > the holiday period. I think we should reinstate these, so I've scheduled the
> > next one for Monday 2nd February. Since our last call was at a time
> > convenient for Asia, this one is at a time that's more convenient for people
> > based in the USA. As for previous calls, I'll post a recording to youtube
> > afterwards for anybody who can't make it.
> > >
> > > I don't have an agenda yet, but will send one out in advance of the
> > meeting.
> >
> > This is right after FOSDEM and many people will be returning home.
> 
> Good point. Thanks for pointing this out. I'll move the meeting to avoid this
> clash.

To avoid the clash, I've moved this to Thursday 5th Feb, at the same time 
(17:00 GMT). Hopefully that's a more convenient time for most people.

Meeting time:
Dublin (Ireland), Thursday, February 5, 2015 at 5:00:00 PMGMT UTC   
 
San Francisco (U.S.A. - California), Thursday, February 5, 2015 at 9:00:00 AM   
 PST UTC-8 hours
Phoenix (U.S.A. - Arizona), Thursday, February 5, 2015 at 10:00:00 AM   MST 
UTC-7 hours
New York (U.S.A. - New York), Thursday, February 5, 2015 at 12:00:00 Noon EST 
UTC-5 hours
Ottawa (Canada - Ontario), Thursday, February 5, 2015 at 12:00:00 Noon EST 
UTC-5 hours
Paris (France), Thursday, February 5, 2015 at 6:00:00 PMCET UTC+1 hour 
Tel Aviv (Israel), Thursday, February 5, 2015 at 7:00:00 PMIST UTC+2 hours  
  
Moscow (Russia), Thursday, February 5, 2015 at 8:00:00 PMMSK UTC+3 hours
New Delhi (India - Delhi), Thursday, February 5, 2015 at 10:30:00 PM   IST 
UTC+5:30 hours 
Shanghai (China - Shanghai Municipality), Friday, February 6, 2015 at 1:00:00 
AM   CST UTC+8 hours
Tokyo (Japan), Friday, February 6, 2015 at 2:00:00 AM   JST UTC+9 hours
Corresponding UTC (GMT), Thursday, February 5, 2015 at 17:00:00

GoToMeeting Details:
To join, follow the meeting link: 
https://global.gotomeeting.com/join/557845085. This will start the GoToMeeting 
web viewer. You then have two options for audio:

1. To use your computer's audio via a headset, you need to switch to the 
desktop version of GoToMeeting. You can do this by clicking the GoToMeeting 
icon on the top right hand side of the web viewer, and then selecting "Switch 
to the desktop version". The desktop version will need to download and install, 
so if you plan to use this you may want to get it set up in advance. Once it 
starts, under the Audio section, you can select "Mic & Speakers". The desktop 
version is only available for Windows and Mac, so if you're using Linux then 
you need to use option 2 below.

2. You can join using a phone via one of the numbers listed below. The Access 
Code is 557-845-085. You'll also be asked for an Audio PIN, which is accessible 
by clicking the phone icon in the GoToMeeting web viewer after you've joined 
the meeting.
Canada +1 (647) 497-9391
France +33 (0) 170 950 593
Ireland +353 (0) 15 290 180
United Kingdom +44 (0) 20 3713 5028
United States +1 (646) 982-0002
More phone numbers: https://global.gotomeeting.com/557845085/numbersdisplay.html

Info on downloading the desktop app is available at: 
http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title=Download%7D
Info on the web viewer is available at: 
http://support.citrixonline.com/en_US/GoToMeeting/help_files/GTM130019?title=Web+Viewer+FAQs


Thanks,
Tim

[dpdk-dev] DPDK Community Call, Monday 2nd February, 17:00 GMT

[O'driscoll, Tim]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, January 20, 2015 5:11 PM
> To: O'driscoll, Tim
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK Community Call, Monday 2nd February, 17:00
> GMT
> 
> On Tue, 20 Jan 2015 15:21:40 +
> "O'driscoll, Tim" <tim.o'driscoll at intel.com> wrote:
> 
> > We had our last community call in December, and then took a break over
> the holiday period. I think we should reinstate these, so I've scheduled the
> next one for Monday 2nd February. Since our last call was at a time
> convenient for Asia, this one is at a time that's more convenient for people
> based in the USA. As for previous calls, I'll post a recording to youtube
> afterwards for anybody who can't make it.
> >
> > I don't have an agenda yet, but will send one out in advance of the
> meeting.
> 
> This is right after FOSDEM and many people will be returning home.

Good point. Thanks for pointing this out. I'll move the meeting to avoid this 
clash.


Tim

[dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation

[O'driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Tuesday, January 20, 2015 2:24 PM
> To: Iremonger, Bernard
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation
> 
> On Tue, Jan 20, 2015 at 01:37:35PM +, Iremonger, Bernard wrote:
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas
> Monjalon
> > > Sent: Tuesday, January 20, 2015 7:15 AM
> > > To: Neil Horman
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation
> > >
> > > Thank you Neil for writing this document.
> > > This is a really important change in DPDK.
> > > It would be very good to have comments or acknowledgement from
> several developpers. This policy
> > > would be enforced by having several Acked-by lines.
> > >
> > >
> > > 2015-01-16 10:33, Neil Horman:
> > > > Adding a document describing rudimentary ABI policy and adding notice
> > > > space for any deprecation announcements
> > > >
> > > > Signed-off-by: Neil Horman 
> > > > CC: Thomas Monjalon 
> > > > CC: "Richardson, Bruce" 
> > > >
> > > > ---
> > > > Change notes:
> > > >
> > > > v5) Updated documentation to add notes from Thomas M.
> > > > ---
> > > >  doc/abi.txt | 36 
> > > >  1 file changed, 36 insertions(+)
> > > >  create mode 100644 doc/abi.txt
> > > >
> > > > diff --git a/doc/abi.txt b/doc/abi.txt new file mode 100644 index
> > > > 000..14be464
> > > > --- /dev/null
> > > > +++ b/doc/abi.txt
> > > > @@ -0,0 +1,36 @@
> > > > +ABI policy:
> > > > +   ABI versions are set at the time of major release labeling, and 
> > > > ABI
> > > > +may change multiple times between the last labeling and the HEAD
> > > > +label of the git tree without warning
> > > > +
> > > > +   ABI versions, once released are available until such time as 
> > > > their
> > > > +deprecation has been noted here for at least one major release cycle,
> > > > +after it has been tagged.  E.g. the ABI for DPDK 1.8 is shipped, and
> > > > +then the decision to remove it is made during the development of
> DPDK
> > > > +1.9.  The decision will be recorded here, shipped with the DPDK 1.9
> > > > +release, and actually removed when DPDK
> > > > +1.10 ships.
> > > > +
> > > > +   ABI versions may be deprecated in whole, or in part as needed 
> > > > by a
> > > > +given update.
> > > > +
> > > > +   Some ABI changes may be too significant to reasonably maintain
> > > > +multiple versions of.  In those events ABI's may be updated without
> > > > +backward compatibility provided.  The requirements for doing so are:
> > > > +   1) At least 3 acknoweldgements of the need on the dpdk.org
> > > > +   2) A full deprecation cycle must be made to offer downstream
> > > > +consumers sufficient warning of the change.  E.g. if dpdk 2.0 is
> > > > +under development when the change is proposed, a deprecation
> notice
> > > > +must be added to this file, and released with dpdk 2.0.  Then the
> change may be incorporated for
> > > dpdk 2.1
> > > > +   3) The LIBABIVER variable in the makefilei(s) where the ABI 
> > > > changes
> > > > +are incorporated must be incremented in parallel with the ABI changes
> > > > +themselves
> > > > +
> > > > +   Note that the above process for ABI deprecation should not be
> > > > +undertaken lightly.  ABI stability is extreemely important for
> > > > +downstream consumers of the DPDK, especially when distributed in
> > > > +shared object form.  Every effort should be made to preserve ABI
> > > > +whenever possible.  For instance, reorganizing public structure field
> > > > +for astetic or readability purposes should be avoided as it will
> > > > +cause ABI breakage.  Only significant (e.g. performance) reasons
> should be seen as cause to alter
> > > ABI.
> >
> > Hi Thomas,
> >
> > Should there be a reference to this document in the programmers guide?
> >
> Thats a good question. I think, as Thomas notes, it probably should be
> referenced in some way.  The programmers guide might be good.  What
> might be
> better would be checking the deprecation notices and adding them to the
> release
> notes for any given release.
> 
> Thoughts?

I'd suggest that the policy itself should go in, or at least be referenced 
from, the programmer's guide. I agree that the deprecation notices themselves 
should go in the release notes.

> Neil
> 
> > Regards,
> >
> > Bernard.
> >
> >

[dpdk-dev] Why nothing since 1.8.0?

[O'driscoll, Tim]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Sunday, January 18, 2015 6:25 PM
> To: O'driscoll, Tim
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> 
> On Sat, Jan 17, 2015 at 07:57:04PM +, O'driscoll, Tim wrote:
> > I'm going to risk the wrath of the open source purists amongst you by top-
> posting. The reason is that there has been lots of email on this subject, and 
> I
> want to summarise the key issue and clearly state our position on it.
> Hoperfully nobody is offended by this!
> >
> Acutally, I am a bit upset by your doing this.  While top posting can be an
> acceptible response form, doing so in an interleaved thread gives you the
> opportunity to effectively rewrite the conversation on your own terms.
> While
> you might have summarized your position accurately in your mind, you've
> discarded all the evidence that I presented in opposition.  I don't appreciate
> that.  But we can rebuild from here, no worries.
> 
> > This thread has generated lots of debate, which is good, and there are a
> number of items that I believe everybody agrees on (having a MAINTAINERS
> file, better tools etc.). However, the key issue that we do not agree on is 
> the
> granularity of the repositories within DPDK.
> >
> No, thats not really the crux of the debate in my mind anymore, though that
> is
> certainly part of it, as it effects the convienience of developers to 
> contribute
> to the project.  More to the point, the area of disagreement here is the best,
> most efficient way to integrate patches to various pieces of the dpdk that
> balances developer convienience, effiency and transparency (I've not
> ennumerated
> that last part before, as I've not thought of the right word, and that may 
> still
> not be quite right, but more on it later).
> 
> > The current state is:
> > - One master repository
> > - A small number of sub-repositories, each with a separate
> maintainer/SME, including: i40e, fm10k, bnx2x, docs, dts. These are used to
> generate pull requests to the main repo.
> >
> No, this is not the current state.  The current state is:
> - One master repository

We have a repository for docs, with a separate maintainer that was used to 
generate pull requests for 1.8. From our perspective that worked well.
For i40e, 1.8 development was done in the main repository, and we agreed to 
transition to a separate repo for 2.0. 2.0 development is currently in progress.
We haven't upstreamed anything for fm10k yet, but that will be done in its own 
repo from the start, for the 2.0 release.

> We have lots of cloned dpdk trees on dpdk.org, but there is no path from
> them to
> the master repository.  Nothing has been comitted to any of the subtrees,
> despite having been open for a few months now.

The plan is to use the i40e and fm10k repos for 2.0 development, which is in 
progress.

>  I don't see any
> documentation
> indicating who the maintainer of each tree is, and so don't have the foggiest
> idea who to contact if I want to get something merged to these trees.  They
> aren't subtrees, they're just clones of the master repository.

A MAINTAINERS file to clarify responsibilities is a good idea.

> > You're proposing the following:
> > - Remove the individual PMD repositories, and replace them with a single
> repository containing all PMDs, plus parts of the core code that are closely
> linked to the PMDs, with you as the maintainer and SMEs for each PMD.
> >
> Not necesarily me, mind you (though yes, I've volunteered).  I'm happy for
> someone else to take on this role if they volunteer.  The point is not to have
> a
> separate repo to integrate patches for any one PMD (as theres no need, and
> it
> makes development harder).  I want one repository that I can use to target
> development against all PMDs, just like we do with net/net-next in the linux
> community.
> 
> > As I've said before, and as Venky has also explained in private email on 
> > this,
> we do not agree with this proposed change. We believe it would be a
> backward step, and would have an adverse impact on DPDK.
> >
> You've asserted that several times, but not once have you provided any
> supporting evidence or data to back that assertion.  Conversely I've provided
> several bits of evidence to support my assertion that using the linux
> workflow
> model would work perfectly well here and handle all our needs (which
> include,
> but are not limited to, yours).

The reason is to give as much control as possible to the people most familiar 
with the PMD code and the corresponding NIC hardware.

> > The key issue here is that we've deliberately tried

[dpdk-dev] Why nothing since 1.8.0?

[O'driscoll, Tim]

I'm going to risk the wrath of the open source purists amongst you by 
top-posting. The reason is that there has been lots of email on this subject, 
and I want to summarise the key issue and clearly state our position on it. 
Hoperfully nobody is offended by this!

This thread has generated lots of debate, which is good, and there are a number 
of items that I believe everybody agrees on (having a MAINTAINERS file, better 
tools etc.). However, the key issue that we do not agree on is the granularity 
of the repositories within DPDK.

The current state is:
- One master repository
- A small number of sub-repositories, each with a separate maintainer/SME, 
including: i40e, fm10k, bnx2x, docs, dts. These are used to generate pull 
requests to the main repo.

You're proposing the following:
- Remove the individual PMD repositories, and replace them with a single 
repository containing all PMDs, plus parts of the core code that are closely 
linked to the PMDs, with you as the maintainer and SMEs for each PMD. 

As I've said before, and as Venky has also explained in private email on this, 
we do not agree with this proposed change. We believe it would be a backward 
step, and would have an adverse impact on DPDK.

The key issue here is that we've deliberately tried to give as much control as 
possible to those who are intimately familiar with a particular PMD and the 
underlying hardware. In our view, that's just common sense. What you're 
proposing is to take some of that control away, and give it to someone else (in 
this case you) who isn't familiar with the details. We don't agree with that 
approach.

The arguments I've heard in favour of your proposal are summarised below. 
Apologies for paraphrasing, and for any errors, but the email thread is too big 
and too convoluted to address these all separately. I've also included an 
explanation for each item to say why we don't believe they're sufficient to 
justify your proposed change.

1. Your proposal is consistent with the Linux kernel, but current state is not.
In both cases (current state and your proposal), the workflow is exactly the 
same as the Linux kernel. The difference we're discussing is simply the 
granularity of the repositories.

DPDK is much smaller than the kernel, so the granularity is naturally going to 
be different. The kernel may combine drivers into a single repository due to 
its size and complexity, but that doesn't mean we need to do the same for DPDK.

2. Maintainer and SME are separate roles and should not be combined.
We understand that they're separate roles. For the PMDs that we're developing, 
the most efficient way for us to manage the work is to combine these and have 
one of our SMEs act as maintainer as well. That's an internal decision that 
suits the structure of our development team and the current state of the i40e 
and fm10k PMDs. Others are obviously free to make their own choices for PMDs 
that they're developing.

3. A maintainer can handle a higher volume of patches than will be present in 
any individual PMD.
That's true, but it's also not relevant. Our goal is not to make the 
SME/maintainer for i40e, fm10k etc. a full-time position. Our goal is to have 
an expert in this position, so that we can move quickly and still ensure good 
quality software.

4. We shouldn't give maintainer work to an SME as it detracts from their other 
tasks.
We don't anticipate a problem with workload for the people that we have in 
these positions.

5. There will be extra overhead for developers who want to implement changes 
spanning multiple PMDs.
That's true, but it's also something of a hypothetical argument. The people 
who've spoken against your proposal on the mailing list are from Intel and 
6Wind, who are also the people contributing to most of these PMDs. I had a 
quick scan of the commits to see if I could spot anything from another 
contributor that might fall into this category, and I couldn't (admittedly it 
wasn't an exhaustive search, which someone else is free to do if they want). If 
this situation does arise, then Thomas has previously outlined how it can be 
handled.


In terms of where we go from here, I'd suggest the following:
- Thomas has already asked us about a maintainer for older Intel NICs, which 
we're looking into. We may choose to have a single repository with a single 
maintainer/SME for e1000/igb/ixgbe combined, which would limit the overall 
number of repositories.
- You could pursue a path of having a single repository for non-Intel NICs. 
This would obviously need to be worked with those responsible (Stephen, Sujith 
etc.).
- As Thomas previously suggested, we should review this in future, possibly 
after 2.0. Maybe you'll be proven right and we'll all have to apologise for 
disagreeing!


Tim

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, January 16, 2015 4:51 PM
> To: O'driscoll, Tim
> Cc: Thomas Monjalon; dev at dpdk.or

[dpdk-dev] Why nothing since 1.8.0?

[O'driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, January 15, 2015 6:51 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> 
> On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > 2015-01-15 08:06, Neil Horman:
> > > On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> > > > 2015-01-15 04:27, Ouyang, Changchun:
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil
> Horman
> > > > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger
> wrote:
> > > > > > > > Ok, so 1.8.0 came out almost a month ago and none of the
> patches
> > > > > > > > that were deferred waiting for the release got merged since
> then.
> > > > > > > > Last commit in git is the 1.8.0 release.
> > > > > > > >
> > > > > > > > Where is the post-merge window bundle, where are the later
> commits?
> > > > > > > > Lots of patches are sitting rotting in patchwork...
> > > > > > >
> > > > > > > +1, I've had the same questions.
> > > > > > > Neil
> > > > > >
> > > > > > +1, Some patch set might be ready for being merged.
> > > > >
> > > > > +1,  the earlier some patches are merged into mainline, and the easier
> those
> > > > > sequent patch sets can resolve their conflicts.
> > > >
> > > > +1, there are some patches which are properly reviewed
> > > >
> > > > Reminder: sub-tree to manage specific part of DPDK can be open on
> request
> > >
> > > Ok, I think what you're saying here is you're too busy to handle all the
> patches
> > > comming in at the moment.  As such I'd like to propose a sub-tree
> encompassing
> > > all the pmds in DPDK.  I would envision that including all the acutal 
> > > pmd's
> in
> > > the tree, as well as the infrastructure that is used to interface them to 
> > > the
> > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch 
> > > pool
> > > and send you pull requests.
> >
> > The list of PMDs is increasing:
> > librte_pmd_af_packet
> > librte_pmd_bond
> > librte_pmd_e1000
> > librte_pmd_enic
> > librte_pmd_i40e
> > librte_pmd_ixgbe
> > librte_pmd_pcap
> > librte_pmd_ring
> > librte_pmd_virtio
> > librte_pmd_vmxnet3
> > librte_pmd_xenvirt
> > There is already some sub-trees for bnx2x, fm10k and i40e:
> > http://dpdk.org/browse/
> >
> Yes, and I've mentioned before that that is an absolutely silly way to break
> out
> subtrees.  You have to find a balance of workload distribution and developer
> convienience.
> 
> I also note that these are problematic because you're not merging anything
> from them. Is it your intention to keep bnx2 and fm10k separate in
> perpituity?
> If so, thats a real problem, because then we effectively just have several out
> of tree drivers, and thats just unacceptible.
> 
> > > If you could set me up with a login to dpdk.org, I'd appreciate it.
> >
> > It is preferred to have 1 sub-tree per module.
> > What do you think of managing contributions for af_packet and/or virtio?
> > It would make sense as virtio is a RedHat technology.
> > Maybe it could include vhost lib and example.
> >
> No, for reasons I've mentioned before.  If you take each pmd/library and
> create
> a subtree for it, you've created the most fine grained control of subtrees you
> could ask for, but you've created a nighmare of a burden on developers who
> want
> to update any code, especially if they have patches that hit multiple trees.
> 
> Look at some of the stats in the dpdk tree:
> 
> Library   Commits between 1.7.0 and 1.8.0
> librte_acl5
> librte_cfgfile0
> librte_cmdline4
> librte_compat 0
> librte_distributor5
> librte_eal125
> librte_ether  31
> librte_hash   1
> librte_ip_frag5
> librte_ivshmem0
> librte_kni2
> librte_kvargs 0
> librte_lpm1
> librte_malloc 1
> librte_mbuf   39
> librte_mempool4
> librte_meter  0
> librte_net4
> librte_pipeline   0
> librte_pmd_af_packet  4
> librte_pmd_bond   20
> librte_pmd_e1000  21
> librte_pmd_enic   12
> librte_pmd_i40e   90
> librte_pmd_ixgbe  83
> librte_pmd_pcap   4
> librte_pmd_ring   0
> librte_pmd_virtio 21
> librte_pmd_vmxnet321
> librte_pmd_xenvirt6
> librte_port   6
> librte_power  3
> librte_ring   2
> librte_sched  1
> librte_table  7
> librte_timer  0
> librte_vhost  30
> 
> If you look at all of the pmds in the dpdk tree, we're talking about ~300
> patches per release.  If you look at the net-next tree for the linux kernel,
> Dave Miller merged 569 patches on his own (based on the following
> command:
> git log 

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[O'driscoll, Tim]

> On Thursday, January 15, 2015  at 8:34 PM, Ravi Kerur  
> wrote:
> 
> On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon
> 
> wrote:
> 
> > 2015-01-09 04:41, Ravi Kerur:
> > > Thomas,
> > >
> > > Please let me know how I can move forward on this. If i confine changes
> > in
> > > e1000/ directory to e1000_osdep.h file only and the rest in PMD will that
> > > work? The reason I ask is because of following comment  in README file.
> > >
> > > ...
> > > Few changes to the original FreeBSD sources were made to:
> > > - Adopt it for PMD usage mode:
> > > e1000_osdep.c
> > > e1000_osdep.h
> > > ...
> >
> > This is an Intel driver so you should ask to the responsible of this code
> > at Intel.
> > The problem is that there is not really an identified responsible for this
> > driver.
> >
> > The rule is to not change the base driver, even osdep files.
> > But it would be better to have an exception here.
> >
> >
> > PS: please avoid top-posting.
> >
> 
>  Please let me know who is the contact person from Intel so I can add
> him/her to "To" list when I send the patch or Should I contact Jim St Leger
> and ask him about this?

We're looking into this, but don't have a definitive answer yet. Somebody from 
Intel will reply as soon as we've confirmed whether the change you proposed is 
OK or not.


Tim

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[O'driscoll, Tim]

Hi Olga,

> Can you please send the presentations from last Community Call.
> We have Tetsuya's presentation,  if we can also get other presentations it 
> will
> be great

No problem. Changchun's slides on the converged Virtio driver and Marvin's 
slides on the DPDK Test Suite are attached.


Tim

-- next part --
A non-text attachment was scrubbed...
Name: DPDK Test Suite.pdf
Type: application/pdf
Size: 725579 bytes
Desc: DPDK Test Suite.pdf
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: Single Virtio.pdf
Type: application/pdf
Size: 216187 bytes
Desc: Single Virtio.pdf
URL: 

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[O'driscoll, Tim]

Thanks to everybody who attended yesterday's call, particularly those who 
presented:

Tetsuya Mukawa (mukawa at igel.co.jp) on PCI Hot Plug
Changchun Ouyang (changchun.ouyang at intel.com) on a converged Virtio driver
Marvin (Yong) Liu (yong.liu at intel.com) on the DPDK Test Suite

For anybody who missed the call, the video is available at: 
http://youtu.be/uD_cbE4CVe8.


Thanks,
Tim

> -Original Message-
> From: O'driscoll, Tim
> Sent: Friday, November 21, 2014 4:09 PM
> To: dev at dpdk.org
> Subject: Next Community Call, Tuesday 2nd December, 8:00 AM GMT
> 
> We're going to hold our next community call on Tuesday 2nd December. This
> time, we're going to try a time that's more suitable for participants in 
> Asia, so
> we're going to hold it at 8:00 AM GMT. The meeting time in a variety of
> timezones is included below.
> 
> Generally, GoToMeeting worked well last time, although there was a
> limitation that Neil was unable to present slides as he joined from a Linux
> system. We'll stick with GoToMeeting again this time as we don't yet have a
> better solution. Details for joining the GoToMeeting session are included
> below.
> 
> I'll record the session again and post the video to YouTube afterwards for
> anybody who can't make it. This seemed to work well last time, and as Kevin
> pointed out, the audio quality on the recording is good.
> 
> For the agenda, we'd like to discuss the following:
> ? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a
> lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can
> join us to describe his work on this.
> ? DPDK Test Suite. We hope to announce the release of this next week.
> Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe
> the functionality and benefits of this.
> 
> 
> Meeting Time:
> Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC
> Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour
> Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours
> Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3
> hours
> New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST
> UTC+5:30 hours
> Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at
> 4:00:00 PM CST UTC+8 hours
> Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours
> San Francisco (U.S.A. - California) Midnight between Monday, December 1,
> 2014 and Tuesday, December 2, 2014 PST UTC-8 hours
> Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST
> UTC-7 hours
> New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM EST
> UTC-5 hours
> Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST
> UTC-5 hours
> Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00
> 
> 
> GoToMeeting Details:
> To join, follow the meeting link:
> https://global.gotomeeting.com/join/772753069. This will start the
> GoToMeeting web viewer. You then have two options for audio:
> 
> 1. To use your computer's audio via a headset, you need to switch to the
> desktop version of GoToMeeting. You can do this by clicking the
> GoToMeeting icon on the top right hand side of the web viewer, and then
> selecting "Switch to the desktop version". The desktop version will need to
> download and install, so if you plan to use this you may want to get it set up
> in advance. Once it starts, under the Audio section, you can select "Mic &
> Speakers". The desktop version is only available for Windows and Mac, so if
> you're using Linux then you need to use option 2 below.
> 
> 2. You can join using a phone via one of the numbers listed below. The
> Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is
> accessible by clicking the phone icon in the GoToMeeting web viewer after
> you've joined the meeting.
> ? Australia   (Long distance): +61 2 9091 7601
> ? Austria   (Long distance): +43 (0) 7 2088 1036
> ? Belgium   (Long distance): +32 (0) 28 08 4345
> ? Canada   (Long distance): +1 (647) 497-9372
> ? Denmark   (Long distance): +45 (0) 69 91 89 24
> ? Finland   (Long distance): +358 (0) 942 45 0382
> ? France   (Long distance): +33 (0) 170 950 586
> ? Germany   (Long distance): +49 (0) 692 5736 7206
> ? Ireland   (Long distance): +353 (0) 15 255 598
> ? Italy   (Long distance): +39 0 694 80 31 28
> ? Netherlands   (Long distance): +31 (0) 208 084 055
> ? New Zealand   (Long distance): +64 (0) 4 974 7243
> ? Norway   (Long distance): +47 23 96 01 18
> ? Spain   (Long distance): +34 932 20 0506
> ? Sweden   (Long distance): +46 (0) 852 500 182
> ? Switzerland   (Long distance): +41 (0) 435 0824 78
> ? Uni

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[O'driscoll, Tim]

Hi Tetsuya,

It would be great if you could explain your work on hotplug at tomorrow's call. 
I think this is a topic that lots of people will be interested in.

I'm not sure of the policy for sending attachments to the list. Perhaps that's 
something that Thomas can clarify. Can you send the slides to me anyway, just 
in case there's any problem with you presenting them in GoToMeeting tomorrow. I 
will also record the session and post the video for those who can't attend.


Tim

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Monday, December 1, 2014 2:50 AM
> To: O'driscoll, Tim; dev at dpdk.org
> Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00
> AM GMT
> 
> Hi Tim,
> 
> Could I explain port hotplug function at next conference call?
> For this explanation, I've prepared slides. could I send a PDF to this ML?
> That slides describe what is the function, how it works and what is
> current progress.
> And it's under 100KB.
> 
> Regards,
> Tetsuya
> 
> (2014/11/22 1:08), O'driscoll, Tim wrote:
> > We're going to hold our next community call on Tuesday 2nd December.
> This time, we're going to try a time that's more suitable for participants in
> Asia, so we're going to hold it at 8:00 AM GMT. The meeting time in a variety
> of timezones is included below.
> >
> > Generally, GoToMeeting worked well last time, although there was a
> limitation that Neil was unable to present slides as he joined from a Linux
> system. We'll stick with GoToMeeting again this time as we don't yet have a
> better solution. Details for joining the GoToMeeting session are included
> below.
> >
> > I'll record the session again and post the video to YouTube afterwards for
> anybody who can't make it. This seemed to work well last time, and as Kevin
> pointed out, the audio quality on the recording is good.
> >
> > For the agenda, we'd like to discuss the following:
> > ? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a
> lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can
> join us to describe his work on this.
> > ? DPDK Test Suite. We hope to announce the release of this next week.
> Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe
> the functionality and benefits of this.
> >
> >
> > Meeting Time:
> > Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC
> > Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour
> > Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours
> > Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3
> hours
> > New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST
> UTC+5:30 hours
> > Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at
> 4:00:00 PM CST UTC+8 hours
> > Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours
> > San Francisco (U.S.A. - California) Midnight between Monday, December 1,
> 2014 and Tuesday, December 2, 2014 PST UTC-8 hours
> > Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST
> UTC-7 hours
> > New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM
> EST UTC-5 hours
> > Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST
> UTC-5 hours
> > Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00
> >
> >
> > GoToMeeting Details:
> > To join, follow the meeting link:
> https://global.gotomeeting.com/join/772753069. This will start the
> GoToMeeting web viewer. You then have two options for audio:
> >
> > 1. To use your computer's audio via a headset, you need to switch to the
> desktop version of GoToMeeting. You can do this by clicking the
> GoToMeeting icon on the top right hand side of the web viewer, and then
> selecting "Switch to the desktop version". The desktop version will need to
> download and install, so if you plan to use this you may want to get it set up
> in advance. Once it starts, under the Audio section, you can select "Mic &
> Speakers". The desktop version is only available for Windows and Mac, so if
> you're using Linux then you need to use option 2 below.
> >
> > 2. You can join using a phone via one of the numbers listed below. The
> Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is
> accessible by clicking the phone icon in the GoToMeeting web viewer after
> you've joined the meeting.
> > ? Australia   (Long distance): +61 2 9091 7601
> > ? Austria   (Long distance): +43 (0) 7 2088 1036
> > ? Belgium   (Long distance): +32 (0) 28 08 4345
> 

[dpdk-dev] DPDK Community Conference Call - Friday 31st October

[O'driscoll, Tim]

The video is now accessible at: http://youtu.be/AbHQ4YaWY90. Thomas may want to 
add a link to this from somewhere on the dpdk.org page.


Tim

> From: Kevin Wilson [mailto:wkevils at gmail.com]
> 
> Hi,
> >I'll post a recording of it soon.
> Great idea! most welcomed!
> 
> Kevin
> 
> 
> On Thu, Nov 20, 2014 at 3:13 PM, O'driscoll, Tim <tim.o'driscoll at intel.com>
> wrote:
> > Hi Kevin,
> >
> >> From: Kevin Wilson [mailto:wkevils at gmail.com]
> >> > We'll schedule a follow-up call for 2 weeks' time
> >> Just a short question - is this still intended to be held ?
> >
> > We had our second call earlier this week, on Tuesday. I'll post a recording 
> > of
> it soon.
> >
> > The next call will be in 2 weeks' time, probably on Tuesday December 2nd. I
> just need to finalise the time before confirming this. We have had a couple of
> requests to alternate between a time that's suitable for USA/Europe, and
> one that's more suitable for Asia. So, the next call will probably be early 
> in the
> morning in Europe, afternoon in Asia, and the middle of the night in the USA.
> >
> >
> > Tim

[dpdk-dev] Community conference call - Tuesday 18th November

[O'driscoll, Tim]

Hi Mirek,

> From: Walukiewicz, Miroslaw
> Is it a possibility to create some place on dpdk.org available to everyone
> where the slides and recording will be available?

Yes, I've been talking with Thomas about this. I have a recording of the 
meeting, and I'll work with Thomas to find the best way to post it on the 
dpdk.org site so people can access it.


Tim

[dpdk-dev] DPDK Community Conference Call - Friday 31st October

[O'driscoll, Tim]

Hi Kevin,

> From: Kevin Wilson [mailto:wkevils at gmail.com]
> > We'll schedule a follow-up call for 2 weeks' time
> Just a short question - is this still intended to be held ?

We had our second call earlier this week, on Tuesday. I'll post a recording of 
it soon.

The next call will be in 2 weeks' time, probably on Tuesday December 2nd. I 
just need to finalise the time before confirming this. We have had a couple of 
requests to alternate between a time that's suitable for USA/Europe, and one 
that's more suitable for Asia. So, the next call will probably be early in the 
morning in Europe, afternoon in Asia, and the middle of the night in the USA.


Tim

[dpdk-dev] Community conference call - Tuesday 18th November

[O'driscoll, Tim]

Thanks again to those who attended the call yesterday. There was a good 
discussion, and it was more interactive than the previous call, which is what 
we were aiming for. We'll schedule a follow-up call for 2 weeks' time. 

Thanks again to those who presented on the following features:
- ABI Versioning (Neil Horman )
- Uio_pci_generic (Danny.Zhou at intel.com)
- Integrated Qemu Userspace vHost (Huawei.Xie at intel.com)

I have a recording of the session, and will send a link to it soon for anybody 
who missed the call.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim
> Sent: Tuesday, November 18, 2014 12:56 PM
> To: 'dev at dpdk.org'
> Subject: Re: [dpdk-dev] Community conference call - Tuesday 18th
> November
> 
> This is just a reminder of our call later today, which is at 17:00 GMT. The 
> time
> in a variety of timezones is included below.
> 
> We're going to use GoToMeeting this time. If you follow the meeting link
> (https://global.gotomeeting.com/join/843960205), the GoToMeeting web
> viewer will start. You then have two options for audio:
> 
> 1. You can join using a phone via one of the numbers listed below. The
> Access Code is 843-960-205. You'll also be asked for an Audio PIN, which is
> accessible by clicking the phone icon in the GoToMeeting web viewer after
> you've joined the meeting.
> 
> 2. To use your computer's audio via a headset, you need to switch to the
> desktop version of GoToMeeting. You can do this by clicking the
> GoToMeeting icon on the top right hand side of the web viewer, and then
> selecting "Switch to the desktop version". The desktop version will need to
> download and install, so if you plan to use this you may want to get it set up
> in advance. Once it starts, under the Audio section, you can select "Mic &
> Speakers". The desktop version is only available for Windows and Mac, so if
> you're using Linux then you need to use option 1 above.
> 
> Info on downloading the desktop app is available at:
> http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title
> =Download%7D
> Info on the web viewer is available at:
> http://support.citrixonline.com/en_US/GoToMeeting/help_files/GTM13001
> 9?title=Web+Viewer+FAQs
> 
> I plan to record the session in GoToMeeting, and make that recording
> available for anybody who can't attend today.
> 
> 
> Tim
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim
> > Sent: Friday, November 14, 2014 10:53 AM
> > To: 'dev at dpdk.org'
> > Subject: Re: [dpdk-dev] Community conference call - Tuesday 18th
> > November
> >
> > Firstly, due to some conflicts, we're going to move next Tuesday's
> > meeting to
> > 1 hour later. Apologies for the short notice on the change. Here's the
> > new meeting time in a variety of timezones:
> >
> > Dublin (Ireland)Tuesday, November 18, 2014 at
> 5:00:00 PMGMT UTC
> > San Francisco (U.S.A. - California) Tuesday, November 18, 2014 at
> 9:00:00 AMPST UTC-8 hours
> > Phoenix (U.S.A. - Arizona)  Tuesday, November 18, 2014 at
> 10:00:00 AM   MST UTC-7 hours
> > New York (U.S.A. - New York)Tuesday, November 18, 2014
> at 12:00:00 Noon EST UTC-5 hours
> > Ottawa (Canada - Ontario)   Tuesday, November 18, 2014 at
> 12:00:00 Noon EST UTC-5 hours
> > Paris (France)  Tuesday, November 18, 2014 at
> 6:00:00 PMCET UTC+1 hour
> > Tel Aviv (Israel)   Tuesday, November 18, 2014 at
> 7:00:00 PMIST UTC+2 hours
> > Moscow (Russia) Tuesday, November 18, 2014 at
> 8:00:00 PMMSK UTC+3 hours
> > Beijing (China - Beijing Municipality)  Wednesday, November 19, 2014 at
> 1:00:00 AM  CST UTC+8 hours
> > Tokyo (Japan)   Wednesday, November 19, 2014 at
> 2:00:00 AM  JST UTC+9 hours
> > Corresponding UTC (GMT) Tuesday, November 18, 2014 at
> 17:00:00
> >
> >
> > Secondly, we're going to try using GoToMeeting this time. Here are the
> > details:
> > 1. Please join my meeting from your computer, tablet or smartphone on
> > Tue, Nov 18, 5:00 PM GMT Standard Time
> > https://global.gotomeeting.com/join/843960205
> >
> > 2. Use your microphone and speakers (VOIP) for audio. You'll sound
> > best with a headset. You can also call in using your telephone.
> > ? United Kingdom   (Long distance): +44 (0) 20 7151 1818
> > ? Australia   (Long distance): +61 2 8355 1034
> > ? Sweden   (Long distance): +46 (0) 852 500 182
> > ? Canada   (Long distance):

[dpdk-dev] Community conference call - Tuesday 18th November

[O'driscoll, Tim]

This is just a reminder of our call later today, which is at 17:00 GMT. The 
time in a variety of timezones is included below.

We're going to use GoToMeeting this time. If you follow the meeting link 
(https://global.gotomeeting.com/join/843960205), the GoToMeeting web viewer 
will start. You then have two options for audio:

1. You can join using a phone via one of the numbers listed below. The Access 
Code is 843-960-205. You'll also be asked for an Audio PIN, which is accessible 
by clicking the phone icon in the GoToMeeting web viewer after you've joined 
the meeting.

2. To use your computer's audio via a headset, you need to switch to the 
desktop version of GoToMeeting. You can do this by clicking the GoToMeeting 
icon on the top right hand side of the web viewer, and then selecting "Switch 
to the desktop version". The desktop version will need to download and install, 
so if you plan to use this you may want to get it set up in advance. Once it 
starts, under the Audio section, you can select "Mic & Speakers". The desktop 
version is only available for Windows and Mac, so if you're using Linux then 
you need to use option 1 above.

Info on downloading the desktop app is available at: 
http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title=Download%7D
Info on the web viewer is available at: 
http://support.citrixonline.com/en_US/GoToMeeting/help_files/GTM130019?title=Web+Viewer+FAQs

I plan to record the session in GoToMeeting, and make that recording available 
for anybody who can't attend today.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim
> Sent: Friday, November 14, 2014 10:53 AM
> To: 'dev at dpdk.org'
> Subject: Re: [dpdk-dev] Community conference call - Tuesday 18th
> November
> 
> Firstly, due to some conflicts, we're going to move next Tuesday's meeting to
> 1 hour later. Apologies for the short notice on the change. Here's the new
> meeting time in a variety of timezones:
> 
> Dublin (Ireland)  Tuesday, November 18, 2014 at 5:00:00 
> PMGMT UTC
> San Francisco (U.S.A. - California)   Tuesday, November 18, 2014 at 9:00:00 
> AMPST UTC-8 hours
> Phoenix (U.S.A. - Arizona)Tuesday, November 18, 2014 at 10:00:00 
> AM   MST UTC-7 hours
> New York (U.S.A. - New York)  Tuesday, November 18, 2014 at 12:00:00 
> Noon EST UTC-5 hours
> Ottawa (Canada - Ontario) Tuesday, November 18, 2014 at 12:00:00 
> Noon EST UTC-5 hours
> Paris (France)Tuesday, November 18, 2014 at 
> 6:00:00 PMCET UTC+1 hour
> Tel Aviv (Israel) Tuesday, November 18, 2014 at 7:00:00 
> PMIST UTC+2 hours
> Moscow (Russia)   Tuesday, November 18, 2014 at 8:00:00 
> PMMSK UTC+3 hours
> Beijing (China - Beijing Municipality)Wednesday, November 19, 2014 at 
> 1:00:00 AM  CST UTC+8 hours
> Tokyo (Japan) Wednesday, November 19, 2014 at 2:00:00 AM  JST 
> UTC+9 hours
> Corresponding UTC (GMT)   Tuesday, November 18, 2014 at 17:00:00
> 
> 
> Secondly, we're going to try using GoToMeeting this time. Here are the
> details:
> 1. Please join my meeting from your computer, tablet or smartphone on Tue,
> Nov 18, 5:00 PM GMT Standard Time
> https://global.gotomeeting.com/join/843960205
> 
> 2. Use your microphone and speakers (VOIP) for audio. You'll sound best
> with a headset. You can also call in using your telephone.
> ? United Kingdom   (Long distance): +44 (0) 20 7151 1818
> ? Australia   (Long distance): +61 2 8355 1034
> ? Sweden   (Long distance): +46 (0) 852 500 182
> ? Canada   (Long distance): +1 (647) 497-9372
> ? Finland   (Long distance): +358 (0) 942 45 0382
> ? Ireland   (Long distance): +353 (0) 15 255 598
> ? Germany   (Long distance): +49 (0) 692 5736 7206
> ? Italy   (Long distance): +39 0 693 38 75 53
> ? Netherlands   (Long distance): +31 (0) 208 080 212
> ? Austria   (Long distance): +43 (0) 7 2088 3707
> ? Belgium   (Long distance): +32 (0) 28 08 9460
> ? United States   (Long distance): +1 (626) 521-0013
> ? Denmark   (Long distance): +45 (0) 89 88 03 61
> ? Switzerland   (Long distance): +41 (0) 435 0824 78
> ? France   (Long distance): +33 (0) 170 950 588
> ? Norway   (Long distance): +47 21 04 29 76
> ? New Zealand   (Long distance): +64 (0) 9 887 3469
> ? Spain   (Long distance): +34 932 20 0506
> 
> Access Code: 843-960-205
> Audio PIN: Shown after joining the session
> 
> Not at your computer? Click the link to join this meeting from your iPhone?,
> iPad?, Android? or Windows Phone? device via the GoToMeeting app.
> 
> 
> Finally, what we'd like to discuss are the candidate features for the 2.0
> release that we didn't c

[dpdk-dev] Community conference call - Tuesday 18th November

[O'driscoll, Tim]

Firstly, due to some conflicts, we're going to move next Tuesday's meeting to 1 
hour later. Apologies for the short notice on the change. Here's the new 
meeting time in a variety of timezones:

Dublin (Ireland)Tuesday, November 18, 2014 at 
5:00:00 PMGMT UTC 
San Francisco (U.S.A. - California) Tuesday, November 18, 2014 at 9:00:00 
AMPST UTC-8 hours 
Phoenix (U.S.A. - Arizona)  Tuesday, November 18, 2014 at 10:00:00 
AM   MST UTC-7 hours 
New York (U.S.A. - New York)Tuesday, November 18, 2014 at 12:00:00 
Noon EST UTC-5 hours 
Ottawa (Canada - Ontario)   Tuesday, November 18, 2014 at 12:00:00 
Noon EST UTC-5 hours 
Paris (France)  Tuesday, November 18, 2014 at 6:00:00 
PMCET UTC+1 hour  
Tel Aviv (Israel)   Tuesday, November 18, 2014 at 
7:00:00 PMIST UTC+2 hours 
Moscow (Russia) Tuesday, November 18, 2014 at 8:00:00 PMMSK 
UTC+3 hours 
Beijing (China - Beijing Municipality)  Wednesday, November 19, 2014 at 1:00:00 
AM  CST UTC+8 hours 
Tokyo (Japan)   Wednesday, November 19, 2014 at 2:00:00 
AM  JST UTC+9 hours 
Corresponding UTC (GMT) Tuesday, November 18, 2014 at 17:00:00 


Secondly, we're going to try using GoToMeeting this time. Here are the details:
1. Please join my meeting from your computer, tablet or smartphone on Tue, Nov 
18, 5:00 PM GMT Standard Time https://global.gotomeeting.com/join/843960205

2. Use your microphone and speakers (VOIP) for audio. You'll sound best with a 
headset. You can also call in using your telephone.  
? United Kingdom   (Long distance): +44 (0) 20 7151 1818  
? Australia   (Long distance): +61 2 8355 1034  
? Sweden   (Long distance): +46 (0) 852 500 182  
? Canada   (Long distance): +1 (647) 497-9372  
? Finland   (Long distance): +358 (0) 942 45 0382  
? Ireland   (Long distance): +353 (0) 15 255 598  
? Germany   (Long distance): +49 (0) 692 5736 7206  
? Italy   (Long distance): +39 0 693 38 75 53  
? Netherlands   (Long distance): +31 (0) 208 080 212  
? Austria   (Long distance): +43 (0) 7 2088 3707  
? Belgium   (Long distance): +32 (0) 28 08 9460  
? United States   (Long distance): +1 (626) 521-0013  
? Denmark   (Long distance): +45 (0) 89 88 03 61  
? Switzerland   (Long distance): +41 (0) 435 0824 78  
? France   (Long distance): +33 (0) 170 950 588  
? Norway   (Long distance): +47 21 04 29 76  
? New Zealand   (Long distance): +64 (0) 9 887 3469  
? Spain   (Long distance): +34 932 20 0506  

Access Code: 843-960-205 
Audio PIN: Shown after joining the session 

Not at your computer? Click the link to join this meeting from your iPhone?, 
iPad?, Android? or Windows Phone? device via the GoToMeeting app. 


Finally, what we'd like to discuss are the candidate features for the 2.0 
release that we didn't cover last time. These include:
? ABI Versioning
? DPDK support for uio_pci_generic
? Integrated Qemu Userspace vHost
? PCI Hot Plug
? Single Virtio Driver
? X32 ABI
? AVX2 ACL
? Interrupt mode for PMD
? DPDK Headroom


Thanks,
Tim

> -Original Message-
> From: O'driscoll, Tim
> Sent: Tuesday, November 11, 2014 10:16 AM
> To: dev at dpdk.org
> Subject: Community conference call - Tuesday 18th November
> 
> We're going to hold our next community conference call a week from today -
> Tuesday 18th November, at 4:00pm in Ireland/UK. Here's the time in a
> variety of timezones:
> 
> Dublin (Ireland)  Tuesday, November 18, 2014
> at 4:00:00 PM  GMT UTC
> San Francisco (U.S.A. - California)   Tuesday, November 18, 2014 at
> 8:00:00 AM  PST UTC-8 hours
> Phoenix (U.S.A. - Arizona)Tuesday, November 18, 2014 at
> 9:00:00 AM  MST UTC-7 hours
> New York (U.S.A. - New York)  Tuesday, November 18, 2014 at
> 11:00:00 AM EST UTC-5 hours
> Ottawa (Canada - Ontario) Tuesday, November 18, 2014 at
> 11:00:00 AM EST UTC-5 hours
> Paris (France)Tuesday, November 18, 2014 at
> 5:00:00 PM  CET UTC+1 hour
> Tel Aviv (Israel) Tuesday, November 18, 2014 at
> 6:00:00 PM  IST UTC+2 hours
> Moscow (Russia)   Tuesday, November 18, 2014 at
> 7:00:00 PM  MSK UTC+3 hours
> Corresponding UTC (GMT)   Tuesday, November 18, 2014 at
> 16:00:00
> 
> I'll provide conference bridge numbers later, but I wanted to communicate
> the date and time now.
> 
> 
> Tim

[dpdk-dev] Community conference call - Tuesday 18th November

[O'driscoll, Tim]

We're going to hold our next community conference call a week from today - 
Tuesday 18th November, at 4:00pm in Ireland/UK. Here's the time in a variety of 
timezones:

Dublin (Ireland)Tuesday, November 18, 2014 at 
4:00:00 PM  GMT UTC 
San Francisco (U.S.A. - California) Tuesday, November 18, 2014 at 8:00:00 
AM  PST UTC-8 hours 
Phoenix (U.S.A. - Arizona)  Tuesday, November 18, 2014 at 9:00:00 
AM  MST UTC-7 hours 
New York (U.S.A. - New York)Tuesday, November 18, 2014 at 11:00:00 
AM EST UTC-5 hours 
Ottawa (Canada - Ontario)   Tuesday, November 18, 2014 at 11:00:00 
AM EST UTC-5 hours 
Paris (France)  Tuesday, November 18, 2014 at 5:00:00 
PM  CET UTC+1 hour  
Tel Aviv (Israel)   Tuesday, November 18, 2014 at 
6:00:00 PM  IST UTC+2 hours 
Moscow (Russia) Tuesday, November 18, 2014 at 7:00:00 PM  MSK 
UTC+3 hours 
Corresponding UTC (GMT) Tuesday, November 18, 2014 at 16:00:00

I'll provide conference bridge numbers later, but I wanted to communicate the 
date and time now.


Tim

[dpdk-dev] [PATCH v4 00/10] VM Power Management

[O'driscoll, Tim]

> From: Carew, Alan
> 
> > Did you make any progress in Qemu/KVM community?
> > We need to be sync'ed up with them to be sure we share the same goal.
> > I want also to avoid using a solution which doesn't fit with their plan.
> > Remember that we already had this problem with ivshmem which was
> > planned to be dropped.
> >
. . .
> 
> Unfortunately, I have not yet received any feedback:
> http://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg01103.html

Just to add to what Alan said above, this capability does not exist in qemu at 
the moment, and based on there having been no feedback on the qemu mailing list 
so far, I think it's reasonable to assume that it will not be implemented in 
the immediate future. The VM Power Management feature has also been designed to 
allow easy migration to a qemu-based solution when this is supported in future. 
Therefore, I'd be in favour of accepting this feature into DPDK now.

It's true that the implementation is a work-around, but there have been similar 
cases in DPDK in the past. One recent example that comes to mind is userspace 
vhost. The original implementation could also be considered a work-around, but 
it met the needs of many in the community. Now, with support for vhost-user in 
qemu 2.1, that implementation is being improved. I'd see VM Power Management 
following a similar path when this capability is supported in qemu.


Tim

[dpdk-dev] DPDK Community Conference Call - Friday 31st October

[O'driscoll, Tim]

Thanks again to those who attended the call earlier. Hopefully people found it 
useful.

We'll schedule a follow-up call for 2 weeks' time. One thing that we do want to 
look into is an easy way to allow screen sharing, so that we can use some 
slides to guide the discussion. Internally within Intel we use MS Lync. We can 
try that, but it's not always very user-friendly for external participants, and 
doesn't have a Linux client. Other options would include GoToMeeting or WebEx. 
If anybody has input on a good tool for this, let me know.

We covered the following features from our 2.0 list today, and will discuss the 
remainder on the next call. I've called out below who on our side was 
describing each of the features, and included their email addresses. If anybody 
has further questions on these, feel free to either ask openly on the mailing 
list, or else contact the relevant person directly.

Bifurcated Driver (Danny.Zhou at intel.com)
Packet Reordering/Packet Distributor (Bruce.Richardson at intel.com)
New Hardware Support (Walter.E.Gilmore at intel.com)
Fortville features (Heqing.Zhu at intel.com)
Support Multiple Threads per Core (Venky.Venkatesan at intel.com)
Cuckoo Hash (Bruce.Richardson at intel.com, Venky.Venkatesan at intel.com)

The Cuckoo Hash paper that was mentioned is available at: 
http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf.

Finally, if anybody has suggestions for topics for future calls, please let me 
know.


Thanks,
Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim
> Sent: Friday, October 31, 2014 3:35 PM
> To: 'dev at dpdk.org'
> Subject: Re: [dpdk-dev] DPDK Community Conference Call - Friday 31st
> October
> 
> This is just a reminder for anybody who's interested that this will be on in 
> 30
> minutes, and that we'll be discussing the feature list for the DPDK 2.0 
> release
> in March 2015.
> 
> Audio bridge details are:
> France:   +33 1588 77298
> Germany:  +49 8999 143191
> Israel:   +972 2589 6577
> Russia:   +7 495 641 4663
> UK:   +44 1793 402663
> USA/Canada:   +1 916 356 2663 or +1-888-875-9370
> 
> Bridge: 5
> Conference ID: 1264677285
> 
> 
> Tim
> 
> > -Original Message-
> > From: O'driscoll, Tim
> > Sent: Friday, October 24, 2014 10:22 AM
> > To: dev at dpdk.org
> > Subject: DPDK Community Conference Call - Friday 31st October
> >
> > We're planning to hold our first community conference call on Friday
> > 31st October. It's impossible to find a time that suits everybody, so
> > we've chosen to do this in the afternoon/evening in Europe, which is
> > the morning in the USA. This does unfortunately limit participation
> > from PRC, Japan and other parts of the world. Here's the time and date in a
> variety of time zones:
> >
> > Dublin (Ireland)Friday, October 31, 2014 at
> > 4:00:00 PMGMT UTC
> > Paris (France)  Friday, October 31, 2014 at 
> > 5:00:00
> > PMCET UTC+1 hour
> > San Francisco (U.S.A. - California) Friday, October 31, 2014 at 9:00:00
> > AMPDT UTC-7 hours
> > New York (U.S.A. - New York)Friday, October 31, 2014 at
> 12:00:00
> > Noon EDT UTC-4 hours
> > Tel Aviv (Israel)   Friday, October 31, 2014 at
> 6:00:00
> > PMIST UTC+2 hours
> > Moscow (Russia) Friday, October 31, 2014 at 7:00:00
> > PMMSK UTC+3 hours
> >
> >
> > Audio bridge details are:
> > France: +33 1588 77298
> > Germany:+49 8999 143191
> > Israel: +972 2589 6577
> > Russia: +7 495 641 4663
> > UK: +44 1793 402663
> > USA:+1 916 356 2663
> >
> > Bridge: 5
> > Conference ID: 1264677285
> >
> > If anybody needs an access number for another country, let me know.
> >
> >
> > Agenda:
> > Discuss feature list for DPDK 2.0 (Q1 2015).
> > Suggestions for topics for future calls.
> >
> >
> > Thanks,
> > Tim

[dpdk-dev] DPDK Community Conference Call - Friday 31st October

[O'driscoll, Tim]

This is just a reminder for anybody who's interested that this will be on in 30 
minutes, and that we'll be discussing the feature list for the DPDK 2.0 release 
in March 2015.

Audio bridge details are:
France: +33 1588 77298
Germany:+49 8999 143191
Israel: +972 2589 6577
Russia: +7 495 641 4663
UK: +44 1793 402663
USA/Canada: +1 916 356 2663 or +1-888-875-9370

Bridge: 5
Conference ID: 1264677285


Tim

> -Original Message-
> From: O'driscoll, Tim
> Sent: Friday, October 24, 2014 10:22 AM
> To: dev at dpdk.org
> Subject: DPDK Community Conference Call - Friday 31st October
> 
> We're planning to hold our first community conference call on Friday 31st
> October. It's impossible to find a time that suits everybody, so we've chosen
> to do this in the afternoon/evening in Europe, which is the morning in the
> USA. This does unfortunately limit participation from PRC, Japan and other
> parts of the world. Here's the time and date in a variety of time zones:
> 
> Dublin (Ireland)  Friday, October 31, 2014 at
> 4:00:00 PMGMT UTC
> Paris (France)Friday, October 31, 2014 at 
> 5:00:00
> PMCET UTC+1 hour
> San Francisco (U.S.A. - California)   Friday, October 31, 2014 at 9:00:00
> AMPDT UTC-7 hours
> New York (U.S.A. - New York)  Friday, October 31, 2014 at 12:00:00
> Noon EDT UTC-4 hours
> Tel Aviv (Israel) Friday, October 31, 2014 at 
> 6:00:00
> PMIST UTC+2 hours
> Moscow (Russia)   Friday, October 31, 2014 at 7:00:00
> PMMSK UTC+3 hours
> 
> 
> Audio bridge details are:
> France:   +33 1588 77298
> Germany:  +49 8999 143191
> Israel:   +972 2589 6577
> Russia:   +7 495 641 4663
> UK:   +44 1793 402663
> USA:  +1 916 356 2663
> 
> Bridge: 5
> Conference ID: 1264677285
> 
> If anybody needs an access number for another country, let me know.
> 
> 
> Agenda:
> Discuss feature list for DPDK 2.0 (Q1 2015).
> Suggestions for topics for future calls.
> 
> 
> Thanks,
> Tim

[dpdk-dev] DPDK Community Conference Call - Friday 31st October

[O'driscoll, Tim]

We're planning to hold our first community conference call on Friday 31st 
October. It's impossible to find a time that suits everybody, so we've chosen 
to do this in the afternoon/evening in Europe, which is the morning in the USA. 
This does unfortunately limit participation from PRC, Japan and other parts of 
the world. Here's the time and date in a variety of time zones:

Dublin (Ireland)Friday, October 31, 2014 at 
4:00:00 PMGMT UTC 
Paris (France)  Friday, October 31, 2014 at 5:00:00 PM  
  CET UTC+1 hour  
San Francisco (U.S.A. - California) Friday, October 31, 2014 at 9:00:00 AM  
  PDT UTC-7 hours 
New York (U.S.A. - New York)Friday, October 31, 2014 at 12:00:00 
Noon EDT UTC-4 hours 
Tel Aviv (Israel)   Friday, October 31, 2014 at 
6:00:00 PMIST UTC+2 hours 
Moscow (Russia) Friday, October 31, 2014 at 7:00:00 PMMSK 
UTC+3 hours


Audio bridge details are:
France: +33 1588 77298
Germany:+49 8999 143191
Israel: +972 2589 6577
Russia: +7 495 641 4663
UK: +44 1793 402663
USA:+1 916 356 2663

Bridge: 5
Conference ID: 1264677285

If anybody needs an access number for another country, let me know.


Agenda:
Discuss feature list for DPDK 2.0 (Q1 2015).
Suggestions for topics for future calls.


Thanks,
Tim

[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

[O'driscoll, Tim]

> From: Matthew Hall [mailto:mhall at mhcomputing.net]
> 
> On Wed, Oct 22, 2014 at 01:48:36PM +, O'driscoll, Tim wrote:
> > Single Virtio Driver: Merge existing Virtio drivers into a single
> > implementation, incorporating the best features from each of the
> > existing drivers.
> 
> Specifically, in the virtio-net case above, I have discovered, and Sergio at 
> Intel
> just reproduced today, that neither virtio PMD works at all inside of
> VirtualBox. One can't init, and the other gets into an infinite loop. But yet 
> it's
> claiming support for VBox on the DPDK Supported NICs page though it
> doesn't seem it ever could have worked.

At the moment, within Intel we test with KVM, Xen and ESXi. We've never tested 
with VirtualBox. So, maybe this is an error on the Supported NICs page, or 
maybe somebody else is testing that configuration.

> So I'd like to request an initiative alongside any virtio-net and/or vmxnet3
> type of changes, to make some kind of a Virtualization Test Lab, where we
> support VMWare ESXi, QEMU, Xen, VBox, and the other popular VM
> systems.
> 
> Otherwise it's hard for us community / app developers to make the DPDK
> available to end users in simple, elegant ways, such as packaging it into
> Vagrant VM's, Amazon AMI's etc. which are prebaked and ready-to-run.

Expanding the scope of virtualization testing is a good idea, especially given 
industry trends like NFV. We're in the process of getting our DPDK Test Suite 
ready to push to dpdk.org soon. The hope is that others will use it to validate 
changes they're making to DPDK, and contribute test cases so that we can build 
up a more comprehensive set over time.

One area where this does need further work is in virtualization. At the moment, 
our virtualization tests are manual, so they won't be included in the initial 
DPDK Test Suite release. We will look into automating our current 
virtualization tests and adding these to the test suite in future.

> Another thing which would help in this area would be additional
> improvements to the NUMA / socket / core / number of NICs / number of
> queues autodetections. To write a single app which can run on a virtual card,
> a hardware card without RSS available, and a hardware card with RSS
> available, in a thread-safe, flow-safe way, is somewhat complex at the
> present time.
> 
> I'm running into this in the VM based environments because most VNIC's
> don't have RSS and it complicates the process of keeping consistent state of
> the flows among the cores.

This is interesting. Do you have more details on what you're thinking here, 
that perhaps could be used as the basis for an RFC?


Tim

[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

[O'driscoll, Tim]

> From: lukego at gmail.com [mailto:lukego at gmail.com] On Behalf Of Luke 
> Gorrie
>
> On 22 October 2014 15:48, O'driscoll, Tim <tim.o'driscoll at intel.com> wrote:
>
> Single Virtio Driver: Merge existing Virtio drivers into a single 
> implementation, incorporating
> the best features from each of the existing drivers.
>
> Cool. Do you have a strategy in mind already for zero-copy optimisation with 
> VMDq? I have
> seen some patches floating around for this and it's an area of active 
> interest for myself and
> others. I see a lot of potential for making this work more effectively with 
> some modest
> extensions to Virtio and guest behaviour, and would love to meet kindred 
> spirits who are
> thinking along these lines too.

At the moment, we're not planning any additional work in this area. We would be 
interested in hearing more details on your thoughts for improvements in this 
area though, and I'm sure others in the community would be interested in this 
too. Have you thought about submitting an RFC to prompt a discussion on this?


Tim

[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

[O'driscoll, Tim]

> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> 
> (2014/10/22 22:48), O'driscoll, Tim wrote:
> > Single Virtio Driver: Merge existing Virtio drivers into a single
> implementation, incorporating the best features from each of the existing
> drivers.
> 
> It's nice plan. We should do it.
> In my understanding, the following drivers could be merged into a single
> virtio PMD since they consist of similar code for handling the virtio ring.
> 
> - librte_pmd_virtio
> - librte_pmd_xenvirt
> - librte_vhost (cuse)
> 
> librte_vhost is not a PMD, but we can easily write a librte_pmd_vhost based
> on librte_vhost.
> Before doing it, we need to consider vhost-user extension for librte_vhost.
> 
> BTW, I have a RFC patch for librte_vhost to handle vhost-user.
> It may be the first step to merge all virtio drivers.
> 
> My patch introduces an abstraction layer to hide differences between legacy
> cuse vhost and vhost-user from DPDK apps.
> Also in my patch, virtio negotiation and initialization code and virtio 
> handling
> code is separated.
> So, legacy cuse vhost and vhost-user can share virtio handling code
> 
> Anyway, I will send a RFC patch soon as the first step of merging all virtio
> drivers.

That's great Tetsuya. There was some discussion on the mailing list previously 
on vhost-user in response to an RFC from Huawei Xie 
(http://dpdk.org/ml/archives/dev/2014-August/004875.html). If you're planning 
an additional RFC on this, that should help to progress things and to make sure 
we're not duplicating work.


Tim

[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

[O'driscoll, Tim]

> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> 
> (2014/10/22 22:48), O'driscoll, Tim wrote:
> 
> > PCI Hot Plug: When you migrate a VM, you need hot plug support as the
> new VF on the new hardware you are running on post-migration needs to be
> initialized. With an emulated NIC migration is seamless as all configuration 
> for
> the NIC is within the RAM of the VM and the hypervisor. With a VF you have
> actual hardware in the picture which needs to be set up properly.
> 
> I have patch series for that feature.
> The patches add feature that DPDK apps can attach and detach physical NIC
> ports and virtual device ports at runtime.
> Also I have patches for testpmd to attach and detach ports dynamically.
> 
> For example, after patching, we can type following commands.
> testpmd> port attach p :02:00.0
> testpmd> port attach v eth_pcap0,iface=eth0 port detach p  testpmd> port_id> port detach v 
> (These are just RFC.)
> 
> Now I am collecting up patches to submit to dpdk.org. So I can send RFC
> patches soon. Hopefully next week.

That's great. I also heard privately from another person who is also working on 
patches for this. If you can submit an RFC, then we should be able to have a 
discussion on it and avoid duplication of effort.


Tim

[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

[O'driscoll, Tim]

We're starting to plan our DPDK features for next year. We're planning to have 
a DPDK 2.0 release at the end of March, and we'd like to inform the community 
of the features that we hope to submit to that release. The current list of 
features, along with brief descriptions, is included below.

There will naturally be some changes to this list as work on these features 
progresses. Some will inevitably turn out to be bigger than anticipated and 
will need to be deferred to a later date, while other priorities will arise and 
need to be accommodated. So, this list will be subject to change, and should be 
taken as guidance on what we hope to submit, not a commitment.

Our aim in providing this information now is to solicit input from the 
community. We'd like to make sure we avoid duplication or conflicts with work 
that others are planning, so we'd be interested in hearing any plans that 
others in the community have for contributions to DPDK in this timeframe. This 
will allow us to build a complete picture and ensure we avoid duplication of 
effort. 

I'm sure people will have questions, and will be looking for more information 
on these features. Further details will be provided by the individual 
developers over the next few months. We aim to make better use of the RFC 
process in this release, and provide early outlines of the features so that we 
can obtain community feedback as soon as possible.

We also said at the recent DPDK Summit that we would investigate holding 
regular community conference calls. We'll be scheduling the first of these 
calls soon, and will use this to discuss the 2.0 (Q1 2015) features in a bit 
more detail.


2.0 (Q1 2015) DPDK Features:
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.

Support the new Intel SoC platform, along with the embedded 10GbE NIC.

Packet Reordering: Assign a sequence number to packets on Rx, and then provide 
the ability to reorder on Tx to preserve the original order.

Packet Distributor (phase 2): Implement the following enhancements to the 
Packet Distributor that was originally delivered in the DPDK 1.7 release: 
performance improvements; the ability for packets from a flow to be processed 
by multiple worker cores in parallel and then reordered on Tx using the Packet 
Reordering feature; the ability to have multiple Distributors which share 
Worker cores.

Support Multiple Threads per Core: Use Linux cgroups to allow multiple threads 
to run on a single core. This would be useful in situations where a DPDK thread 
does not require the full resources of a core.

Support the Fedora 21 OS.

Support the host interface for Intel's next generation Ethernet switch. This 
only covers basic support for the host interface. Support for additional 
features will be added later.

Cuckoo Hash: A new hash algorithm was implemented as part of the Cuckoo Switch 
project (see http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf), and shows 
some promising performance results. This needs to be modified to make it more 
generic, and then incorporated into DPDK.

Provide DPDK support for uio_pci_generic.

Integrated Qemu Userspace vHost: Modify Userspace vHost to use Qemu version 
2.1, and remove the need for the kernel module (cuse.ko).

PCI Hot Plug: When you migrate a VM, you need hot plug support as the new VF on 
the new hardware you are running on post-migration needs to be initialized. 
With an emulated NIC migration is seamless as all configuration for the NIC is 
within the RAM of the VM and the hypervisor. With a VF you have actual hardware 
in the picture which needs to be set up properly.

Additional XL710/X710 40-Gigabit Ethernet Controller Features:  Support for 
additional XL710/X710 40-Gigabit Ethernet Controller features, including 
bandwidth and QoS management, NVGRE and other network overlay support, TSO, 
IEEE1588, DCB support.  SR-IOV switching and port mirroring.

Single Virtio Driver: Merge existing Virtio drivers into a single 
implementation, incorporating the best features from each of the existing 
drivers.

X32 ABI: This is an application binary interface project for the Linux kernel 
that allows programs to take advantage of the benefits of x86-64 (larger number 
of CPU registers, better floating-point performance, faster 
position-independent code shared libraries, function parameters passed via 
registers, faster syscall instruction) while using 32-bit pointers and thus 
avoiding the overhead of 64-bit pointers.

AVX2 ACL: Modify ACL library to use AVX2 instructions to improve performance.

Interrupt mode for PMD: Allow DPDK process to transition to interrupt mode when 
load is low so that other processes can run, or else power can be saved. This 
will increase latency/jitter.

DPDK Headroom: Provide a mechanism to indicate how much headroom (spare 
capacity) exists in a 

[dpdk-dev] to the intel dpdk engineers and all contributors

[O'driscoll, Tim]

Thanks Daniel. I'm sure the many people who've put a lot of time and effort 
into building DPDK will really appreciate your kind words.


Tim

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of daniel chapiesky
> Sent: Wednesday, October 15, 2014 9:47 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] to the intel dpdk engineers and all contributors
> 
> I just watched the closing remarks by Tim Driscol at the dpdk summit
> 
> http://youtu.be/r-JA5NBybrs
> 
> At time 4:30, he mentioned the "shock to the system" of developers
> expecting a pat on the back and instead receiving critiques of their code.
> 
> I realized that I was one of those who failed to acknowledge the incredible
> work the Intel Engineers and other contributors have produced.
> 
> Please let me acknowledge all of you and your efforts with a few comments:
> 
> 1) Kudos!!:
> 
> 2) The Packet Framework made me run around waving my hands in the air
> yelling: "This is freaking awesome! I don't have to write it myself!!!"
> 
> 3) The layered architecture is elegant.
> 
> 4) Examples The examples are wonderful! Those who wrote the
> examples are my heroes.
> 
> 5) Docs? Clear, to the point, and better than the other projects we depend
> upon (you know who you are)
> 
> 6) 6Wind - Thank you for taking on the management of the repository and
> website - your coordination effort is truly appreciated
> 
> 7) Did I say the Packet Framework saved me so much time I was actually able
> to cut back my coffee intake by 10%
> 
> 8) Windriver - PktGen!  (though I really want to know more about
> mcos)
> 
> Finally,
> 
> I recently received a pat on the back for the application I have developed.
> In truth, that pat should be passed on, since my application depends so
> heavily on DPDK.
> 
> Thank you.
> 
> I encourage others to let the Intel Engineers and contributors know how
> much we appreciate the time and effort they have given to DPDK.
> 
> Sincerely,
> 
> 
> Daniel Chapiesky
> AllSource