[dpdk-dev] DPDK Meet-up in Boston area
Hi everyone, We are hosting another DPDK meet-up in the Boston area next week, Wednesday October 18th - this time in the Red Hat offices in Westford, MA. You can find more information about the meet-up, including (when I put them up) our speaker line-up. https://www.meetup.com/BostonSoftwareNetworking/events/243865692/ We will have 2-3 presentations, plus some social food and drink time. If you are in the area, and available for the evening, we will start things off at 6pm, and start presentations by 6:30pm. Please sign up so that we have an idea of numbers! 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] DPDK Meet-up in Boston: Wed July 12th
Hi all, Thanks to Rashid Khan and Aaron Conole, we have secured some space for a DPDK meet-up in our home town of Boston next Wednesday, July 12th, at the Red Hat offices in Fort Point (300 A St, Boston, MA). This is a first one, so the agenda is light, we will have an introduction to the meet-up group, and an overview of what to expect in DPDK 17.08, and a group discussion of how we can do more regular meet-ups in the future. If you are in the Boston area and have an interest in DPDK, please consider signing up below (so that we have an idea how many people we can expect) and joining us next Wednesday! Thanks also to Mark Presti, who shared the Boston Software Networking meet-up page with us to plan the event on meet-up! https://www.meetup.com/BostonSoftwareNetworking/events/241390595/ Thank you all, 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] Project Governance and Linux Foundation
Hi all, We had a great session yesterday on this topic, I took some notes - does anyone who was there have any corrections, or anyone who was not have any comments? Thanks, Dave. Tim led the discussion, and started by outlining that he saw there were 3 different questions which we should treat independently: 1. Is there a benefit to moving DPDK to a foundation? 2. If the answer is yes: there are two options currently proposed - a low overhead, independent project under the Linux Foundation (LF Lite), or joining fd.io as a sub-project. Which one of these is preferable, or is there another option to consider? 3. Are there any related changes we should consider in technical infrastructure and project governance? I outlined some advantages I see to the Linux Foundation: * Pool resources for events * Provides some legal foresight * LF standing behind a project gives some companies assurances that there is good, open technical governance and a level playing field for participants Stephen Hemminger asked if there was a sponsorship requirement. Tim responded that it is possible to do what Open vSwitch has done, and have no membership funding requirement. What that means is that any funds the project community wants to spend needs to be budgeted ad hoc. A number of others (Shreyansh Jain, Matt Spencer) said they would like to see a formal model for non-technical engagement, legal protection for patent and copyright, and more clarity on the technical governance. Vincent Jardin said that whatever happens, it is vital that DPDK remain an open, community-run project. A number of people expressed interest in the change, but could not commit to funding. Jerome Tollet said that he felt it was important to have better test and CI infrastructure, and that these cost money. He proposed that since fd.io already has infrastructure and a lab, that this would be an affordable option for doing this. Vincent and Thomas Monjalon suggested that distributed testing was a better option - creating an opportunity for different people to send test results to a central gathering point. Thomas mentioned that Patchwork has a feature which allows aggregation of test results for specific patches now. Tim asked if there was agreement on a move, and there was no opposition. Vincent suggested opening a call for proposals to have a wider range of choices than LF Lite or fd.io. Jim St. Leger said we have already had a group who evaluated options and made a proposal, and we should not re-do the process. Jerome recommended that we focus on requirements and criteria for determining the choice: timing, governance requirements, budget, and hardware/infrastructure requirements. Keith Wiles suggested that there was a need for some budgetary requirement to show commitment of participating companies. When asked about transferring the ownership of the domain name to Linux Foundation, Vincent reiterated that his main concern was keeping the project open, and that he did not anticipate that transferring the domain ownership would be an issue. Moving on to question 2: I said that Red Hat is happy with the technical operation of the project, and we don't want to see the community disrupted with toolset changes - and it's possible to work with projects like fd.io, OVS, and OPNFV to do testing of DPDK. Representatives from Brocade, Cavium, and Linaro all voiced a preference for a stand-alone lightweight project - one concern voiced was that there is a potential perception issue with fd.io too. Maciek K and Jerome encouraged everyone not to underestimate the difficulty in setting up good CI and testing processes. To close out the meeting, Tim summarised the consensus decisions: * We agreed to move to a foundation * A group will work on re-doing a budget proposal with the Linux Foundation - target of 4 weeks to come up with a budget proposal for the community * There is a preference for an independent project rather than being a sub-project Budget group: * Matt Spencer, ARM * Jerome Tollet, Cisco * Ed Warnicke, Cisco * Shreyansh Jain, NXP * Dave Neary, Red Hat * Jan Blunk, Brocade * Vincent Jardin, 6WIND * Thomas Monjalon, 6WIND * Tim O'Driscoll, Intel * Francois Ozog, Linaro * John Bromhead (sp?), Cavium On 10/10/2016 09:33 AM, O'Driscoll, Tim wrote: > 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
[dpdk-dev] Project Governance and Linux Foundation
Hi, On 10/19/2016 09:04 AM, O'Driscoll, Tim wrote: >> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] >> 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. The one issue I am aware of is that the Linux Foundation, in our previous discussions, requested that they take ownership of the dpdk.org domain name and management of the DNS, to ensure that the website and community infrastructure were not beholden to a single project member - is that still an issue? Regards, 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] Project Governance and Linux Foundation
Hi, On 10/17/2016 07:52 AM, O'Driscoll, Tim wrote: >> -Original Message- >> 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. I just want to second what Tim said - it's important for Red Hat, at least, that the technical governance of a project be kept separate from any membership of an organization managing the budget for the project. The technical management of the project can also be discussed, but it is out of scope, IMHO, when talking about moving to fd.io or the Linux Foundation. >> 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. 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. Regards, 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] DPDK namespace
Hi, On 04/06/2016 08:07 AM, Panu Matilainen wrote: >> +1: it's a bit weird to keep both, especially for a long while, that >> every time we turn a rte_ prefix to dpdk_ prefix, we break applications. >> Instead of breaking applications many times, I'd prefer to break once. >> Therefore, applications could do a simple global rte_ -> dpdk_ >> substitute: >> it doesn't sound that painful then. > > I concur. If (and I think that should be a pretty big IF) the prefix is > to be changed then its better done in one fast sweep than gradually. > > Gratuitious (or nearly so) change is always extremely annoying, and the > longer it takes the more painful it is. Application developers wont much > care what the prefix is as long as its consistent, but if they're forced > to track prefix changes across several releases with different libraries > moving at different pace, they WILL be calling for bloody murder :) How about the idea of creating (at switch over time) an optionally installable dpdk_compat package that just has a list of #defines for the old symbols pointing them at the new symbols? That would also allow people with old applications to update DPDK without having to modify their applications. 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] [dpdk-announce] technical board
Thank you Thomas, It's great to see progress towards the plans we made in Dublin. Thanks, Dave. On 03/03/2016 06:52 PM, Thomas Monjalon wrote: > There were some discussions to form a technical board for the DPDK: > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/26596 > > After a first meeting of this group, its scope and operation mode > have been approved: > http://dpdk.org/browse/tools/dpdk-web/commit/?id=5833c070 > > So it is now part of the development process: > http://dpdk.org/dev#board > > It is small, simple and easy to understand. > As usual, comments are welcome on the dev@ mailing list. > -- 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] thoughts on DPDK after a few days of reading sources
Hi, On 02/11/2016 02:58 AM, Thomas Monjalon wrote: > 2016-02-10 19:05, Seth Arnold: > [...] >> It's nearly impossible to solve issues without error reporting. Good >> error reporting saves admins time and money. > > Until now, the errors were reported on the list and most often fixed quickly. > While I agree we need a more formal process (a bug tracker), I think we must > be noticed of new bugs on the mailing list. > Since nobody was against the bugzilla proposal, a deployment will be planned. > http://dpdk.org/ml/archives/dev/2015-August/023012.html I may have misunderstood Seth's comment, but it looked like he was talking about checking errno after fopen and reporting the error with perror or strerror in the event of a non-zero return. Seth, did I understand correctly? 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] DPDK Community Call - Linux Foundation
Is there any substantive feedback on this? It seems like silence = consensus (or that the people who might care more are not on this list). My suggestion is to go to the next stage, start drafting a membership agreement and identify potential members to recruit. Will the Linux Foundation take point on recruiting members, or does that fall to the community too? Thanks, Dave. On 02/05/2016 12:20 PM, Bob Monkman wrote: > Right. Yes, I can access it just fine. > Thx, > > > Robert (Bob) Monkman > Enterprise Segment Marketing Manager > 150 Rose Orchard Way > San Jose, Ca 95134 > M: +1.510.676.5490 > > > -Original Message- > From: O'Driscoll, Tim [mailto:tim.odriscoll at intel.com] > Sent: Friday, February 05, 2016 9:09 AM > To: Bob Monkman; dev at dpdk.org; Laura Kempke; Michael Dolan > Subject: RE: DPDK Community Call - Linux Foundation > > >> -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
[dpdk-dev] DPDK Community Call - Linux Foundation
Hi Tim, On 01/22/2016 07:19 PM, O'Driscoll, Tim wrote: > 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. Sounds good to me. All of the times below work. :-) Thanks, Dave. > 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 > > -- 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] releases scheduling
Hi, You could just bump the major version for the first release of the new year - in this case, we would make 2.6 be 3.0. It achieves the same objective without having a big discontinuity in the release numbers. Thanks, Dave. On 12/15/2015 08:37 AM, O'Driscoll, Tim wrote: > >> -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 > -- 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
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? 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] FOSDEM - call for participation
Thank you Thomas! Please note that I made the mistake of leaving some te;mplate from last year's announcement in the email - my apologies! The correct dates for the conference and deadlines are in this version: https://lists.fosdem.org/pipermail/fosdem/2015-November/002300.html Thanks, Dave. On 11/04/2015 06:29 PM, Thomas Monjalon wrote: > As every year, at the end of January, the biggest european developers > conference takes place in Brussels, Belgium. > > This year, there will be an SDN/NFV DevRoom. > You can submit a talk proposal before November 18. > > Topic examples: > * SDN controllers - OpenDaylight, OpenContrail, ONOS, Midonet, OVN, > OpenStack Neutron,Calico, IOvisor, ... > * Dataplane processing: DPDK, OpenDataplane, netdev, netfilter, ClickRouter > * Virtual switches: Open vSwitch, Snabb Switch, VDE, Lagopus > * Open network protocols: OpenFlow, NETCONF, OpenLISP, eBPF, P4, Quagga > * Management and Orchestration (MANO): Deployment and management of > network functions, policy enforcement, virtual network functions > definition - rift.io, Cloudify, OpenMANO, Tacker, ... > * Open source network functions: Clearwater IMS, FreeSWITCH, OpenSIPS, ... > * NFV platform features: Service Function Chaining, fault management, > dataplane acceleration, ... > > The announce by Dave Neary: > https://lists.fosdem.org/pipermail/fosdem/2015-October/002282.html > > It is also a good opportunity to drink some really good beers ;) > -- 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] 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 networkplumber.org>; 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 - NFV/SDN Community Strategy > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +1-978-399-2182 / Cell: +1-978-799-3338 > -- 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] 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 - 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] Architecture Board Proposal
On 10/30/2015 09:25 AM, Thomas Monjalon wrote: > 2015-10-30 13:23, O'Driscoll, Tim: >> From: Dave Neary >>> 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? > > Do we need a board to define the scope of this board? ;) :-) > The only reason I see to reject a project, would be to consider that the > project is not related to DPDK enough. I think it will be an obvious decision. > So it shouldn't be a high responsibility nor a high workload to add to this > board. > But clearly, the hosted projects (except DPDK itself) should not be impacted > by the DPDK board. You have a good point - and in the spirit of "the board exists only to make decisions that aren't converging in the community", maybe we don't need more. 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] 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. 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] Architecture Board Proposal
d 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? I like co-option in this case, but I would like to have some kind of criteria for how board removals can happen - that might be a detail, but it's important that the architect board continue to represent the most influential participants in the community, and I could imagine a scenario where someone named to the board moves to a different position and over the course of 6-12 months is less active in the project - would they be expected to nominate a successor? Withdraw and alow others to nominate? If they don't volunteer to withdraw, what criteria can the board use to request that they withdrawal? One thing I think is important is that seats are not considered "owned" by a company. There isn't a 6WIND seat or an Intel seat - seats are held by individuals representing the interests of the technical community, not companies invested in the project. In general, though, I think 2 seats per company may is a good number, I would not want to have even the perception of a majority voting block by one company. Overall, thanks Tim! I think this is a really solid proposal. 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] [RFC] location for DPDK related white papers
Hi, On 10/23/2015 06:28 AM, Mcnamara, John wrote: > We have had a few people wishing to submit DPDK related white papers. > These tend to focus on particular aspects of DPDK and don't fit into > any of the existing documents. > > Where should these be stored/made available? Some options: > > * In the repo, in RST format in a doc/guides/white_paper directory. This would be my preference. We could create PDF versions alongside them, but the sources should be editable (enables updates over time). > * On dpdk.org in PDF format. > * Elsewhere. > > Any comments, suggestions? 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] New mailing list for users
Thanks Thomas! Great news, I'm signed up and spreading the word via the tweets. Dave. On 10/15/2015 12:26 AM, Thomas Monjalon wrote: > Hello, > > Following this discussion: > http://dpdk.org/ml/archives/dev/2015-October/025032.html > the mailing-list users at dpdk.org has been created. > > Like dev at dpdk.org, you must be registered to post without moderation. > It is a basic spam counter-measure. > > As usual, please try to be friendly and give accurate answers to questions. > The traffic on this list should be low if the documentation is good enough. > If you feel some improvements are required to better help users and reduce > the traffic of this list, do not hesitate to send a patch for the doc ;) > > If you have some patches to send or discuss, please use dev at dpdk.org. > > Welcome DPDK users! > -- 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] DPDK User Space: Session onUseability and Ease of Use
Hi, On 10/13/2015 10:06 PM, Thomas Monjalon wrote: >> * Create a User Mailing List. - Needs support from 6Wind. > > OK > Name: user at dpdk.org or other suggestion? Other pages seem to have standardised on "users" - I don't think it matters much, either is fine. 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] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)
Hi, To explicitly call out the proposals and action items from the meeting: - Legal entity proposal: - PROPOSAL: Chris proposes moving DPDK to Linux Foundation, with low overhead option - Minimal governance, event, marketing budget - Legal governance around project name, trademark - Project leadership proposal (roadmap, scope) - ACTION: Venky to write a proposal for broadening scope as a patch to the website - PROPOSAL: Thomas proposes several smaller projects, rather than one umbrella project as scope broadens - ACTION: Jim proposed documenting current decision process, and improving on it - documenting it will help make it better. - ACTION: Tim proposed to resurface his TSC proposal and drive it to agreement and action - Proposed criteria which should be met by any technical governance model: 1. Everyone has a voice 2. Some voices carry more weight than others, based on technical seniority and participation in the community 3. Decisions should be time bound - after community debate, decision should converge quickly one way or the other to give clarity - Day to day patch review: - PROPOSAL: Thomas: Create hierarchical review process with maintainers responsible for sub-trees (to be housed in DPDK Git) - ACTION: (without owner?) Subtrees and maintainers to be identified, -next, crypto and (drivers, IIRC?) to be first trees - PROPOSAL: Thomas to identify replacement maintainers short-term when he is unable to do it (vacation, sickness, etc) - Stable patch maintenance - PROPOSAL: Maintain one release per year as a long term release, with point releases being made regularly (based on patch volume), with branches maintained for 2 years (2 stable branches + 1 devel branch active at all times). In addition to Thomas's notes, does this cover all of the conclusions that came out of the meeting? Thanks, Dave. On 10/11/2015 01:36 AM, Dave Neary wrote: > Hi everyone, > > I took some notes from a discussion we had at the end of DPDK Userspace > in Dublin, concerning the growth and project structure for DPDK. If I > missed anyone's name, I apologise - there were many active contributors, > including most prominently Venky, Jim St Leger, Bruce Richardson, > Stephen Hemminger, Chris Wright, myself, Keith Wiles, Cristian > Dumitrescu, Tim O'Driscoll, Thomas Monjalon, and (until he had to leave) > Vincent Jardin. There were a few others from Intel, ARM, and others, but > I didn't get all the names during the discussion. If you see a comment > you made and would like attribution, reply - especially if it doesn't > quite match your view. > > The discussion was wide ranging and we didn't quite stay on one topic > until we reached a conclusion, so some of these notes are not in strict > time order. > > These are a mixture of notes and proposals for the project coming out of > the meeting - comments are welcome, all proposals are up for discussion, > and nothing has been decided on the basis of this meeting. However, all > present expressed agreement that there are issues we need to address in > the near future. > > Apologies for the non-linear note taking, for those who were not there I > hope they're useful. > > Thanks, > Dave. > > > > Topic 1: Legal entity > = > > Do we need/want a legal entity independent of a commercial vendor who > can represent the project? > > Things a legal entity could do: > - Sign contracts and raise money for events > - Organise events > - Own the trademark > - Own project infrastructure like DNS, website infrastructure > - Centralised pool for marketing budget? > - Brand awareness? > > There was agreement that legal governance should be lightweight, and > completely independent of technical governance. Vincent insisted on the > low cost structure for entities like 6WIND who would not be able to > justify a 6 figure membership fee. > > Topic 2: Technical governance (roadmap, project scope) > == > > Jim: What if soeone proposes a feature that competes with a commercial > offering from an incumbent? Is it rejected, accepted, ignored? > > Thomas: Issue is one of trust - is Thomas a good maintainer or not? > (language moderated ;-) If we trust the maintainer, then no problem. If > people disagree with Thomas as maintainer, then there are multiple ways > around it - gang up on Thomas & change maintainer, or fork. > > Scope is a big question - is (say) a TCP stack in scope, or not? Website > says no. Thomas replies that website can be changed by a patch - patch > submission would be the start of a scope discussion, and the community > will decide. Venky: Scope narrowed compared to his initial goal - > satisfy needs of high volume s
[dpdk-dev] Notes from project governance meeting at DPDK Userspace
to be reviewers? If not, how do we get to that point? Venky: Performance requires a specific skill set, not everyone has the skills, but slow patch review has an opportunity cost, and we can minimise cost of "bad" reviews with good CI performance tests that catch regressions How do we maintain review velocity when maintainer is unavailable (eg. on vacation)? How does it happen in Linux? - Linus delegates - names "locum" maintainer while he is away. Stephen volunteered to do it for a week or two when necessary. Thomas: Subsystem maintainers carry review weight when maintainer is out. Stephen: Subsystem maintainers are reviewers, need high level of trust to be a top level maintainer. Thomas - Subtrees can live in DPDK git tree, makes it easier to manage merges afterwards. 2 volunteer subtree maintainers - Declan for crypto, Kevin for (not noted). Is it an issue if only Intel people are subtree maintainers? Venky: Yes, should have others. Discussion summary == At this point, we synthesised the conversation and tried to converge on a firm proposal for community discussion & action: - Legal entity: - Propose moving DPDK to Linux Foundation, with low overhead option - Minimal governance, event, marketing budget - Legal governance around project name, trademark - Project leadership (roadmap, scope) - Venky to write a proposal for broadening scope as a patch to the website - Thomas proposes several smaller projects, rather than one umbrella project as scope broadens - Some discussion around whether we should limit to one project per stack? Venky: Prefers not to - Chris: How do decisions on new projects get made? - Stephen: Proposed that in the event of contention, in-person debate and consensus decides - Jim proposed documenting current decision process, and improving on it - documenting it will help make it better. - Proposed criteria which should be met by any technical governance model: 1. Everyone has a voice 2. Some voices carry more weight than others, based on technical seniority and participation in the community 3. Decisions should be time bound - after community debate, decision should converge quickly one way or the other to give clarity Further discussion on the composition and process for choosing a TSC: = - Why not just have all the maintainers act as the TSC? - Too many, but not open enough if community voice is not heard. Maintainers may be tightly focused on one area, and not have overall visibility of the project. Bruce: We should have a TSC. Elected by contributors, with some minimum bar for voting rights & being a candidate (eg. 10 patches) Christian: Thinks it makes sense to first define scope of what a TSC would own, before deciding on a format and process for voting - Bruce: Anything that doesn't reach community consensus gets kicked to TSC - Cristian: Better to only have TSC decide on things which do not have a clear decision path elsewhere (don't 2nd guess maintainer decisions) Dave: Recommended that TSC stay small (4-5 people) Tim will resurface his TSC proposal, revised based on this discussion, for community review and comment. Stable/long-term releases = We finished the discussion with a brief conversation on whether we should maintain certain branches for a long time. Bruce: Adds a lot of overhead Venky: Can do point releases on some branches Stephen: Prepared to "volunteer" someone from Brocade, because they need to maintain an older release anyway. Proposal: How many parallel long-term branches? - One per year (roughly one in 3 releases) - 2 years maintenance after release (3 maintained branches in parallel - 2 long-term, plus trunk) 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] DPDK.org Community Call - Sept 24 - Discuss Growth, Improvements
Hi Jim, I see that there is a session loosely aligned with the agenda below on the agenda for DPDK Userspace in Dublin: https://dpdksummit.com/us/en/userspace2015 (current speaker is TBC). Will this call serve as a preparation call for that face to face meeting? In which case, is this the best opportunity that people who cannot travel to Dublin will have to make any concerns/proposals known so that they can be discussed there? Thanks, Dave. On 09/22/2015 03:14 AM, St Leger, Jim wrote: > I am going to host a community call on Thursday Sept 24 at 7:00am Pacific > daylight time. The conference call dial-in info via GoToMeeting is pasted > below. Here is the background and objective of the discussion. > > The DPDK community continues to grow. Here are some stats on the 2.1 release > from August 17th: > => 827 commits. A growth of ~50% over the 2.0 release. > => 82 individual committers. A growth of ~33% over the 2.0 release. > The number of companies contributing has also continued to grow. > > There is a strong desire to continue to grow and solidify the community. But > the growth brings up the question of how the community is structured to > scale. Additionally, there are many private DPDK repositories across the > industry (e.g. ARM ports, for example.) There are a myriad of reasons why > companies have elected to keep their DPDK code and ports private versus put > them into the DPDK.org community. We as a community need to understand and > explore these reasons and work towards enabling inclusion. > > During this gathering I'd like to bring together the DPDK community including: > a) the DPDK code contributors, > b) the consumers of DPDK downstream (VNF vendors, etc.), > c) private branch DPDK creators/consumers, and > d) anyone else interested in the growth and future of the DPDK open source > software project. > > The call will focus on two topics: > > 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? > > I hope people can attend AND that they will join and speak up and be heard. > The success and growth of the community depends on YOU! > > Thanks, > Jim > = > DPDK Community Call > > Thu, Sep 24, 2015 3:00 PM - 4:00 PM GMT Daylight Time > Please join my meeting from your computer, tablet or smartphone. > https://global.gotomeeting.com/join/766709085 > > You can also dial in using your phone. > > Access Code: 766-709-085 > Dial-in phone numbers > United States : +1 (312) 757-3117 > Australia : +61 2 8355 1031 > Austria : +43 (0) 7 2088 1033 > Belgium : +32 (0) 28 93 7001 > Canada : +1 (647) 497-9371 > Denmark : +45 (0) 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) 20 3713 5010 > > -- 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] Technical Steering Committee (TSC)
Hi, On 05/14/2015 01:55 PM, O'Driscoll, Tim wrote: > 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. As others have said, I think a TSC can have value, more as the "guardian of the roadmap", a place to engage to set high level goals and priorities for the project. And as Neil and Thomas said, I also agree that it does not make sense for the TSC to get involved in the day-to-day of the project (patch review, for example). There is a danger with TSCs that you end up with "design by committee" - but I think that is a risk that can be mitigated by limiting the scope. In terms of membership: I do think it's important to have the voice of users in the technical community, but I agree with Stephen that the TSC would not be the appropriate forum for that. 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] DPDK Community Call - Beyond DPDK 2.0
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? > 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? > 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 perception: DPDK is seen as an Intel platform only project by those outside the project, and dpdk.org is seen as a 6WIND owned community space. I think that it would be valuable to have an independent entity who could, without a huge cost structure, manage the trademark, enable the pooling of resources, and provide a framework for commercial engagement (whether that be through membership, sponsorship, a user advisory group, whatever avenue is most appropriate). Some options I see for that entity are the Software Freedom Conservancy, the Linux Foundation (although I suspect the cost structure would be too high for what we need), Software in the Public Interest, or some new non-profit we create just for DPDK. There are a few other options too. But to evaluate the options, we need the problem statement, and a set of requirements. I don't think we have that yet (my effort at defining the requirements is above). 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] DPDK Community Call - Beyond DPDK 2.0
Hi Tim, When were you thinking of having the call? 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. Thanks, Dave. On 05/01/2015 06:20 PM, O'Driscoll, Tim wrote: > 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 > > -- 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] Beyond DPDK 2.0
Hi, On 04/26/2015 05:56 PM, Neil Horman wrote: > On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote: >> I would like to see some type of layering process to allow patches to be >> applied in a timely manner a few weeks not months or completely ignored. >> Maybe some type of voting is reasonable, but we need to do something to >> turn around the patches in clean reasonable manner. >> >> Think we need some type of group meeting every week to look at the patches >> and determining which ones get applied, this gives quick feedback to the >> submitter as to the status of the patch. >> > I think a group meeting is going to be way too much overhead to manage > properly. > You'll get different people every week with agenda that may not line up with > code quality, which is really what the review is meant to provide. I think > perhaps a better approach would be to require that that code owners from the > maintainer file provide and ACK/NAK on their patches within 3-4 days, and > require a corresponding tree maintainer to apply the patch within 7 or so. > That > would cap our patch latency. Likewise, if a patch slips in creating a > regression, the author needs to be alerted and given a time window in which to > fix the problem before the offending patch is reverted during the QE cycle. What Keith is describing is very similar to a change management/change control board you might find for production/IT processes: http://en.wikipedia.org/wiki/Change_control_board An efficient change management board approves "low overhead" changes automatically/very quickly, and focusses on the 10% of changes which could be disruptive (and what disruptive means changes from one environment to another) - for code it would be any patches that potentially conflict, anything that could cause regressions, add instability or uncertainty, and any feature which can be implemented multiple ways. Not saying this would work - I have never seen an open source project implement a change management process for handling patches, and instinctively I agree with you Neil that it would be a lot of overhead, but it's an interesting thought exercise to think how it might work. 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] Beyond DPDK 2.0
Hi Tim, On 04/23/2015 07:36 AM, O'Driscoll, Tim wrote: >> Alternatively, propose some options and vote, but I don't think we have >> things defined >> enough for that yet. > > We tried to keep the initial communication neutral and avoid suggesting > solutions to give others a chance to comment. At a very high level, there > seem to be 3 possible approaches though: > > 1. Do nothing. The project is increasing in size, and the releases are > getting delivered according to the roadmap, so one option is to continue as > we are. > > 2. Add a more formal governance structure to dpdk.org. This might involve > putting in place a Technical Steering Committee to give long-term technical > direction to the project, and to resolve any differences of opinion that > don't reach a conclusion on the mailing list. > > 3. Transition the project to an organization such as the Linux Foundation, > and use their help to implement a more formal governance structure. This > would probably involve a TSC, and possibly also a governing board and the > creation of some form of centralized marketing/branding/promotional budget > for the project. I see at least one other option, which is to document the process for becoming a maintainer/core reviewer (whatever terminology we choose), and move from a single project lead to multiple committers. This would allow the project to scale, reducing average review time and removing bottlenecks, but would avoid the potential for "design by committee" which a TSC would bring, and also avoid the operational and cost overhead of a formal foundation. This will not address the issue of how the project's scope, priorities and roadmap are defined, but will definitely help with both the scaling of project contributions and the diversity of the project. The MAINTAINERS file: http://dpdk.org/browse/dpdk/tree/MAINTAINERS is an awesome step in the right direction by clearly defining where people maintain a module. Regards, 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] How do I leave this mailing list
Incidentally, this information is contained in the List-Unsubscribe header which Mailman adds to the email headers of every message. "View message source" for the full set (I always use List-Id for mailing list filters). Dave. On 04/22/2015 07:10 PM, Wiles, Keith wrote: > Try going here and you can input your email and password to unsubscribe. > > http://dpdk.org/ml/listinfo/dev > > > Or just here for all email lists: > > http://dpdk.org/ml > > Regards, > ++Keith > > On 4/22/15, 5:23 PM, "Vipin Agrawal" wrote: > >> What do I need to do to not receive any more emails? >> >> Thanks, >> Vipin >> >> >> >> >> >> >> This message is for the designated recipient only and may contain >> privileged, proprietary, or otherwise confidential information. If you >> have received it in error, please notify the sender immediately and >> delete the original. Any other use of the e-mail by you is prohibited. >> Thank you in advance for your cooperation. >> >> > -- 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
