From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 5F9C33B5 for ; Thu, 16 Feb 2017 13:15:43 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 04:15:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,169,1484035200"; d="scan'208,217";a="59164774" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by orsmga004.jf.intel.com with ESMTP; 16 Feb 2017 04:15:41 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by irsmsx110.ger.corp.intel.com ([169.254.15.101]) with mapi id 14.03.0248.002; Thu, 16 Feb 2017 12:15:40 +0000 From: "O'Driscoll, Tim" To: "moving@dpdk.org" Thread-Topic: Minutes from "Moving DPDK to Linux Foundation" call, February 14th Thread-Index: AdKITksatVH9nC0PQE2X5EZxjMxkmg== Date: Thu, 16 Feb 2017 12:15:39 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA722BE7D8@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmE3OGNiOWQtZThhNS00ZGQxLTk2YzktMTU5ZmVkOGM5NTY5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJDXC9lN3dQWmUwTGk4ZndoUGl3OVZPbTVaYkkzaEFLMzhDWDVIcmgySERraz0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: multipart/alternative; boundary="_000_26FA93C7ED1EAA44AB77D62FBE1D27BA722BE7D8IRSMSX108gercor_" MIME-Version: 1.0 Subject: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, February 14th X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:15:44 -0000 --_000_26FA93C7ED1EAA44AB77D62FBE1D27BA722BE7D8IRSMSX108gercor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are my notes from yesterday's call. Please feel free to correct any er= rors or to add additional details. Attendees: Bruce Richardson (Intel), Erez Scop (Mellanox), George Zhao (Hua= wei), Jan Blunck (Brocade), Jaswinder Singh (NXP), Jim St. Leger (Intel), J= ohn Bromhead (Cavium), John McNamara (Intel), Keith Wiles (Intel), Kevin Tr= aynor (Red Hat), Thomas Monjalon (6WIND), Tim O'Driscoll (Intel), Vincent J= ardin (6WIND). Firstly, here are some links to help keep track of things: Project Charter: https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OV= zAuNXtD7dppIhrY48FoGs Budget estimate: https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8M= us9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=3D302618256 Reference Lab Proposal: http://dpdk.org/ml/archives/moving/2017-February/00= 0177.html Technical governance, including info on Maintainers and sub-trees: http://d= pdk.org/doc/guides/contributing/index.html & http://dpdk.org/dev. Summary of discussion at Userspace event in Dublin: http://dpdk.org/ml/arch= ives/dev/2016-October/049259.html Minutes of January 10th call: http://dpdk.org/ml/archives/moving/2017-Janua= ry/000136.html Minutes of January 17th call: http://dpdk.org/ml/archives/moving/2017-Janua= ry/000157.html Minutes of January 24th call: http://dpdk.org/ml/archives/moving/2017-Janua= ry/000162.html Minutes of January 31st call: http://dpdk.org/ml/archives/moving/2017-Febru= ary/000176.html Minutes of February 7th call: http://dpdk.org/ml/archives/moving/2017-Febru= ary/000179.html Open Reference Lab: - Agreed that an Open Reference Lab is a good idea. It would help to identi= fy performance issues and would improve quality and stability. - We discussed whether all performance numbers should be made public. It wa= s felt that there may be cases where some vendors do not want absolute numb= ers published, and that in those cases we could publish delta numbers to sh= ow the difference between one performance test and another. This could happ= en in cases where DPDK is being supported on a new platform (e.g. as is hap= pening now with NXP) and performance has not yet reached the expected level= . This would just be a temporary situation until performance tuning is comp= lete. Thomas suggested that we give each vendor the option, and let them de= cide when they're ready to publish absolute numbers. - Agreed that the lab should be referred to as the Open Reference Lab. - Agreed that the scope is to identify performance regression, not to perfo= rmance test new features and/or new hardware. Vendors will still want to pe= rformance test DPDK on their latest hardware, but that should be done inter= nally in their own labs. - Discussed the frequency of testing. Ideally this would be done per patch = so that we know the performance impacts of each patch and can take that int= o account when agreeing whether the patch should be accepted into DPDK. Tes= ting per patch will increase the resource requirements, so we'll need to ta= ke that into account. - Discussed how we want to maintain the lab. This is related to the decisio= n on where we want to host it. Ideally, it should be administered by people= familiar with DPDK and familiar with the hardware. - Jan suggested looking at how other projects have handled admin for open l= abs. We'll look into this. - Agreed that it would be useful to allow people to submit software applica= tions to be run in the lab, as Matt suggested in a previous discussion. Thi= s will add some complexity. - Discussed how we ensure that the lab doesn't become a competitive environ= ment for vendors to show that their performance is the best. We need to agr= ee some rules to prevent this. - We need to look at hosting options (not just the LF, but other options to= o). To do this, we need to know hardware and power requirements. We haven't= got to that level of detail yet. - We'll discuss further in a smaller group. Anybody interested in participa= ting in those discussions should let me know. Tech Board: - A tech board meeting was held yesterday. Minutes will be published. Makin= g tech board meetings public was one of the agenda items. Next Meeting: Tuesday February 21st at 3pm GMT, 4pm CET, 10am EST, 7am PST. Access number= s for the call are: Skype meeting: https://meet.intel.com/tim.odriscoll/97F0Q1HF France: +33 1588 77298 UK: +44 179340 2663 USA: +1 916 356 2663 Bridge Number: 5 Conference ID: 120705852 We need to discuss how membership discussions are progressing and if our ta= rget date of a project launch to coincide with ONS (http://events.linuxfoun= dation.org/events/open-networking-summit, April 3-6) is realistic. --_000_26FA93C7ED1EAA44AB77D62FBE1D27BA722BE7D8IRSMSX108gercor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are my notes from yesterday's call. Please f= eel free to correct any errors or to add additional details.

 

Attendees: Bruce Richardson (Intel), Erez Scop (M= ellanox), George Zhao (Huawei), Jan Blunck (Brocade), Jaswinder Singh (NXP)= , Jim St. Leger (Intel), John Bromhead (Cavium), John McNamara (Intel), Kei= th Wiles (Intel), Kevin Traynor (Red Hat), Thomas Monjalon (6WIND), Tim O'Driscoll (Intel), Vincent Jardin (6WI= ND).

 

Firstly, here are some links to help keep track o= f things:

Project Charter: https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48= FoGs

Budget estimate: https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJ= V5GnXcLg/edit#gid=3D302618256

Reference Lab Proposal: http://dpdk.org/ml/archives/moving/2017-February/000177.html=

Technical governance, including info on Maintaine= rs and sub-trees: http://dpdk.= org/doc/guides/contributing/index.html & http://dpdk.org/dev.

Summary of discussion at Userspace event in Dubli= n: http://dpdk.org/ml/archives/dev/2016-October/049259.html

Minutes of January 10th call: http://dpdk.org/ml/archives/moving/2017-January/000136.html<= /p>

Minutes of January 17th call: http://dpdk.org/ml/archives/moving/2017-January/000157.html<= /p>

Minutes of January 24th call: http://dpdk.org/ml/archives/moving/2017-January/000162.html<= /p>

Minutes of January 31st call: http://dpdk.org/ml/archives/moving/2017-February/000176.html=

Minutes of February 7th call: http://dpdk.org/ml/archives/moving/2017-February/000179.html=

 

Open Reference Lab:

- Agreed that an Open Reference Lab is a good ide= a. It would help to identify performance issues and would improve quality a= nd stability.

- We discussed whether all performance numbers sh= ould be made public. It was felt that there may be cases where some vendors= do not want absolute numbers published, and that in those cases we could p= ublish delta numbers to show the difference between one performance test and another. This could happen in cases where= DPDK is being supported on a new platform (e.g. as is happening now with N= XP) and performance has not yet reached the expected level. This would just= be a temporary situation until performance tuning is complete. Thomas suggested that we give each vendor = the option, and let them decide when they’re ready to publish absolut= e numbers.

- Agreed that the lab should be referred to as th= e Open Reference Lab.

- Agreed that the scope is to identify performanc= e regression, not to performance test new features and/or new hardware. Ven= dors will still want to performance test DPDK on their latest hardware, but= that should be done internally in their own labs.

- Discussed the frequency of testing. Ideally thi= s would be done per patch so that we know the performance impacts of each p= atch and can take that into account when agreeing whether the patch should = be accepted into DPDK. Testing per patch will increase the resource requirements, so we’ll need to take= that into account.

- Discussed how we want to maintain the lab. This= is related to the decision on where we want to host it. Ideally, it should= be administered by people familiar with DPDK and familiar with the hardwar= e.

- Jan suggested looking at how other projects hav= e handled admin for open labs. We’ll look into this.

- Agreed that it would be useful to allow people = to submit software applications to be run in the lab, as Matt suggested in = a previous discussion. This will add some complexity.

- Discussed how we ensure that the lab doesn̵= 7;t become a competitive environment for vendors to show that their perform= ance is the best. We need to agree some rules to prevent this.

- We need to look at hosting options (not just th= e LF, but other options too). To do this, we need to know hardware and powe= r requirements. We haven’t got to that level of detail yet.

- We’ll discuss further in a smaller group.= Anybody interested in participating in those discussions should let me kno= w.

 

Tech Board:

- A tech board meeting was held yesterday. Minute= s will be published. Making tech board meetings public was one of the agend= a items.

 

 

Next Meeting:

Tuesday February 21st at 3pm GMT, 4pm CET, 10am E= ST, 7am PST. Access numbers for the call are:

  Skype meeting: https://meet.intel.com/tim.odriscoll/97F0Q1HF

  France: +33 1588 77298

  UK: +44 179340 2663

  USA: +1 916 356 2663   =  

  Bridge Number: 5

  Conference ID: 120705852

We need to discuss how membership discussions are= progressing and if our target date of a project launch to coincide with ON= S (http://events.linuxfoundation.org/events/open-networking-summit, April 3-6) is realistic.

 

 

--_000_26FA93C7ED1EAA44AB77D62FBE1D27BA722BE7D8IRSMSX108gercor_--