From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 095694C88 for ; Mon, 4 Mar 2019 18:41:07 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4EA7D22A67; Mon, 4 Mar 2019 12:41:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 04 Mar 2019 12:41:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=JDTtI4zVodkeRR+q0+r3EPIpYTRmsoxBV4DCgL56jwI=; b=WRgPWoEKx7jT HGdeQPv23fNFJ5HrmWkG9SX6OWyGGq4vNKrgLUn9t33P9VCECj4n9/aanEOdnnAw Wr7yrmxXNekavNQLaFz0TBwypE4+XuU9pBpdhKyZA3j6iLfVXfg6ETcOaem99iKQ 5rI0x6kw2VtEORZVnNk09upeyAkcQIU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=JDTtI4zVodkeRR+q0+r3EPIpYTRmsoxBV4DCgL56j wI=; b=lGbNdnympCoF4vBvTZlFWBGUy/6gPhtajAlW/8ahgKc1I+vndmFp7fyzb e5CY3GaVWP8qoHkQveaYcx7cB+r8oQ9nH7hWrZRFGohwvTh0b3gzd9tp1L82L75j 7ZR3h7ZquvX5Y8RJLa81r0TZ88yawRO+e1JK6LYMK6uMMbDuHj2RN0lOVxZ8zoib G2N9Rlj/VOgdgbeMEhmzhOMavScxhrPANrGGOsaNPRkH0sVeQAoiGDqLrTJQX/lq Uq0Da58Jq36J5cgXX8Pmm9kiKtWMgx0NV4cnQ9lE9ZpRQsnrYQQj6NyGaJ2GJtDC 3b+Fnc4t0J1C4vlNgwUfiNsuUGv4A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfedugddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefiedrudekrdefjeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (37.18.136.77.rev.sfr.net [77.136.18.37]) by mail.messagingengine.com (Postfix) with ESMTPA id 90F9C10336; Mon, 4 Mar 2019 12:41:04 -0500 (EST) From: Thomas Monjalon To: Lincoln Lavoie Cc: Aaron Conole , "O'Driscoll, Tim" , "ci@dpdk.org" , "Stokes, Ian" , Rashid Khan Date: Mon, 04 Mar 2019 18:40:59 +0100 Message-ID: <5602454.1Rb4ADb6Bi@xps> In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BAB785C151@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 17:41:08 -0000 04/03/2019 17:59, Lincoln Lavoie: > Hi All, > > The reason we selection loaner machines (UNH provided) for the development > was to avoid interference with the existing setup, i.e. don't break or > degrade the performance tuned systems. > > For the deployed testing (i.e. once we have the OVS developed and > integrated with the lab dashboard) can be done either on the existing > hardware, or a stand alone setup with multiple NICs. I think this was > proposed, because function testing with multiple NICs would had more > hardware coverage than the two vendor performance systems right now. That > might also be a lower bar for some hardware vendors to only provide a NIC, > etc. Either a vendor participate fully in the lab with properly setup HW, or not at all. We did not plan to have half participation. Adding more tests should encourage to participate. > In we choose the "option A" to use the existing performance setups, we > would serialize the testing, so the performance jobs run independently, but > I don't think that was really the question. Yes, it is absolutely necessary to have a serialized job queue, in order to have multiple kinds of tests on the same machine. I think we need some priority levels in the queue. > On Mon, Mar 4, 2019 at 8:06 AM Aaron Conole wrote: > > > "O'Driscoll, Tim" writes: > > > > >> -----Original Message----- > > >> From: Thomas Monjalon [mailto:thomas@monjalon.net] > > >> Sent: Thursday, February 28, 2019 3:20 PM > > >> To: ci@dpdk.org > > >> Cc: O'Driscoll, Tim > > >> Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th > > >> > > >> Hi, > > >> > > >> 28/02/2019 15:49, O'Driscoll, Tim: > > >> > OVS Tests: > > >> > - Jeremy and Aaron are working on setup of the temporary hardware. > > >> > - There are two options for hardware to run this on when the setup is > > >> complete: 1) use existing vendor hardware; 2) obtain standalone servers > > >> for OVS testing. The OVS team's preference is option 2. It's not > > >> realistic to expect a vendor to provide hardware to run a competitor's > > >> products so we'd need to find a different way to procure this. Aaron > > >> will check with Rashid to see if budget is available from Red Hat. I'll > > >> check with Trishan to see if the DPDK project budget could cover this. > > >> > - The OVS focus is on functional tests, not performance tests. The > > >> DPDK lab is currently set up so that each vendor has complete control > > >> over performance tests & results on their hardware. If we use separate > > >> hardware for the OVS tests, we need to ensure that we restrict scope to > > >> functional tests so that it does not conflict with this principle in > > >> future. > > >> > > >> I am not sure to understand. > > >> In my opinion, the purpose of this lab is to have properly tuned > > >> hardware > > >> for running a large set of tests. We should be able to run various > > >> tests > > >> on the same machine. So the OVS tests, like any new test scenario, > > >> should be run on the same machine as the performance tests. > > > > This is definitely something I support as well. > > > > >> I think we just need to have a job queue to run tests one by one, > > >> avoiding a test to disturb results of another one. > > >> > > >> Why are we looking for additional machines? > > > > I think because there is no such kind of job queue available, currently? > > I don't recall if an exact reason was given other than the nebulous fear > > of "breaking the existing setups". > > > > > That was my assumption too. I believe the reason is that the OVS team > > > want to validate with multiple vendor NICs to be sure that nothing is > > > broken. We only have Intel and Mellanox hardware in our lab at > > > present, so we don't cover all vendors. > > > > > > Aaron and Ian can provide more details.