Re: [openstack-dev] Testing NUMA, CPU pinning and large pages
> -Original Message- > From: Steve Gordon [mailto:sgor...@redhat.com] > Sent: Wednesday, February 11, 2015 8:49 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Znoinski, Waldemar > Subject: Re: [openstack-dev] Testing NUMA, CPU pinning and large pages > > - Original Message - > > From: "Adrian Hoban" > > > > Hi Folks, > > > > I just wanted to share some details on the Intel CI testing strategy for > > NFV. > > > > You will see two Intel CIs commenting: > > #1: Intel-PCI-CI > > - Yongli He and Shane Wang are leading this effort for us. > > - The focus in this environment is on PCIe and SR-IOV specific testing. > > - Commenting back to review.openstack.org has started. > > With regards to SR-IOV / PCI specifically it seemed based on > https://review.openstack.org/#/c/139000/ and > https://review.openstack.org/#/c/141270/ that there was still some > confusion as to where the tests should actually live (and I expect the same is > true for the NUMA, Large Pages, etc. tests). Is this resolved or are there > still > open questions? > > Thanks, > > Steve > Hi Steve, The PCIe test code is being put on github at: https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases We would readily welcome some feedback if folks think it should go elsewhere, but for now the tests are publically available and we can continue to make progress. Regards, Adrian > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Testing NUMA, CPU pinning and large pages
> -Original Message- > From: Vladik Romanovsky [mailto:vladik.romanov...@enovance.com] > Sent: Wednesday, January 28, 2015 4:10 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][NFV][qa] Testing NUMA, CPU pinning > and large pages > > > > - Original Message - > > From: "Steve Gordon" > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Sent: Tuesday, 27 January, 2015 9:46:44 AM > > Subject: Re: [openstack-dev] [nova][NFV][qa] Testing NUMA, CPU pinning > > and large pages > > > > - Original Message - > > > From: "Vladik Romanovsky" > > > To: openstack-dev@lists.openstack.org > > > > > > Hi everyone, > > > > > > Following Steve Gordon's email [1], regarding CI for NUMA, SR-IOV, > > > and other features, I'd like to start a discussion about the NUMA > > > testing in particular. > > > > > > Recently we have started a work to test some of these features. > > > The current plan is to use the functional tests, in the Nova tree, > > > to exercise the code paths for NFV use cases. In general, these will > > > contain tests to cover various scenarios regarding NUMA, CPU > > > pinning, large pages and validate a correct placement/scheduling. > > > > Hi Vladik, > > > > There was some discussion of the above at the Nova mid-cycle > > yesterday, are you able to give a quick update on any progress with > > regards to creation of the above functional tests? > > > > I have a some progress, however, currently I have some challenges with > validating the scheduler filters outcome. I'll try to post some of it in the > coming days. > > > > In addition to the functional tests in Nova, we have also proposed > > > two basic scenarios in Tempest [2][3]. One to make sure that an > > > instance can boot with a minimal NUMA configuration (a topology that > > > every host should have) and one that would request an "impossible" > > > topology and fail with an expected exception. > > > > We also discussed the above tempest changes and they will likely > > receive some more review cycles as a result of this discussion but it > > looks like there is already some feedback from Nikola that needs to be > > addressed. More broadly for the list it looks like we need to > > determine whether adding a negative test in this case is a valid/desireable > use of Tempest. > > I have updated the tempest tests yesterday. The tests were waiting on a > nova patch to be merged: > https://review.openstack.org/#/c/145312 > > However, unfortunately, I've discovered another bug in nova that prevents > the tests from passing, somehow I missed it in the previous attempt: > https://review.openstack.org/#/c/150694 > > Thanks, > Vladik > > > > > Thanks, > > > > Steve > > > > Hi Folks, I just wanted to share some details on the Intel CI testing strategy for NFV. You will see two Intel CIs commenting: #1: Intel-PCI-CI - Yongli He and Shane Wang are leading this effort for us. - The focus in this environment is on PCIe and SR-IOV specific testing. - Commenting back to review.openstack.org has started. #2: Intel-Networking-CI - Waldemar Znoinski is leading this effort for us. - This is really two separate environments under the hood. - The focus of one environment is on our new Neutron ML2 mechanism driver that is in development on stackforge for ovs accelerated with DPDK (i.e. networking-ovs-dpdk). This environment is containers based and commenting back to review.openstack.org has started. - The focus of the second environment is on NUMA (CPU & I/O), CPU pinning and Huge Pages. The tests will be executed on bare-metal based environment and the plan is to have the tests run on this environment commenting back in a few weeks. The combination of PCIe + SR-IOV + NUMA (CPU & I/O) + CPU Pinning + Huge Pages + networking-ovs-dpdk (mech driver) represents our contribution to NFV testing and we think should cover the NFV extensions going into Kilo that require a CI environment. We would really welcome your feedback on this. We will leverage as many of the related tests as possible that are submitted upstream, so the ones noted by Vladik above are of particular interest. Regards, Adrian > __ > > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park
Re: [openstack-dev] [all] The future of the integrated release
> On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote: > > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery > wrote: > > > > I really like this idea, as Michael and others alluded to in > > > > above, we > > > are > > > > attempting to set cycle goals for Kilo in Nova. but I think it is > > > > worth doing for all of OpenStack. We would like to make a list of > > > > key goals > > > before > > > > the summit so that we can plan our summit sessions around the > > > > goals. On a really high level one way to look at this is, in Kilo > > > > we need to pay down our technical debt. > > > > > > > > The slots/runway idea is somewhat separate from defining key cycle > > > goals; we > > > > can be approve blueprints based on key cycle goals without doing slots. > > > But > > > > with so many concurrent blueprints up for review at any given > > > > time, the review teams are doing a lot of multitasking and humans > > > > are not very > > > good at > > > > multitasking. Hopefully slots can help address this issue, and > > > > hopefully allow us to actually merge more blueprints in a given cycle. > > > > > > > I'm not 100% sold on what the slots idea buys us. What I've seen > > > this cycle in Neutron is that we have a LOT of BPs proposed. We > > > approve them after review. And then we hit one of two issues: Slow > > > review cycles, and slow code turnaround issues. I don't think slots > > > would help this, and in fact may cause more issues. If we approve a > > > BP and give it a slot for which the eventual result is slow review > > > and/or code review turnaround, we're right back where we started. > > > Even worse, we may have not picked a BP for which the code submitter > > > would have turned around reviews faster. So we've now doubly hurt > > > ourselves. I have no idea how to solve this issue, but by over > > > subscribing the slots (e.g. over approving), we allow for the > > > submissions with faster turnaround a chance to merge quicker. With > > > slots, we've removed this capability by limiting what is even > > > allowed to be considered for review. > > > > > > > Slow review: by limiting the number of blueprints up we hope to focus > > our efforts on fewer concurrent things slow code turn around: when a > > blueprint is given a slot (runway) we will first make sure the > > author/owner is available for fast code turnaround. > > > > If a blueprint review stalls out (slow code turnaround, stalemate in > > review discussions etc.) we will take the slot and give it to another > blueprint. > > On Wed , Aug 13, 2014 Daniel Berrange wrote: > This idea of fixed slots is not really very appealing to me. It sounds like > we're > adding a significant amount of buerocratic overhead to our development > process that is going to make us increasingly inefficient. > I don't want to waste time wating for a stalled blueprint to time out before > we give the slot to another blueprint. On any given day when I have spare > review time available I'll just review anything that is up and waiting for > review. If we can set a priority for the things up for review that is great > since I > can look at those first, but the idea of having fixed slots for things we > should > review does not do anything to help my review efficiency IMHO. > > I also thing it will kill our flexibility in approving & dealing with changes > that > are not strategically important, but none the less go through our > blueprint/specs process. There have been a bunch of things I've dealt with > that are not strategic, but have low overhead to code and review and easily > dealt with in the slack time between looking at the high priority reviews. It > sounds like we're going to loose our flexibility to pull in stuff like this > if it only > gets a chance when strategically imporatant stuff is not occupying a slot > > Regards, > Daniel > -- I am also not in favour of this fixed slots approach because of the potential lack of flexibility and overhead that could be introduced in the process. There has been lots of great mailing list traffic over the last month about blueprint spec freeze deadlines, exceptions, review priorities, inter-project dependencies on approvals, etc. We had a brief discussion in the NFV working group [1] and this is a really creative thread on how we can address some of the challenges in getting a proposal from concept through to blueprint acceptance and code integration. I think some of the difficulty on converging on a proposal in this thread stems from the number of problem statements that are being addressed simultaneously. In no particular order and not an exhaustive list, here are some of the challenges that I've seen mentioned on this thread and others so far: - There is an imbalance between strategic and tactical submissions. - There is growing technical debt and lack of clarity on how that should be dealt with. - There is inconsistency, and in some cases a lack of clarity, in how the entire lifecycle of
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
+1 for lunch tomorrow -Original Message- From: Chris Wright [mailto:chr...@sous-sol.org] Sent: Thursday, May 15, 2014 11:06 AM To: Steve Gordon; CARVER, PAUL; Stephen Wong; Alan Kavanagh Cc: OpenStack Development Mailing List (not for usage questions); iawe...@cisco.com Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit * Stephen Wong (s3w...@midokura.com) wrote: > A good number of people involved in Neutron advanced service / > group-policy / individual services subteams will be at the Group > Policy conference session (at 1:30pm). Is it possible to reschedule > this to a different time? Urgh, we were looking at design summit sessions only. * Steve Gordon (sgor...@redhat.com) wrote: > > From: "Alan Kavanagh" > > +1 can we reschedule to push this forward Chris please? > > > There are a number of other NFV-related sessions later in the day today as > well (both on the general and design tracks), perhaps the best option would > be to meet during the lunch break tomorrow instead, will enough interested > people still be around? Neutron pod has 2:30 session on QoS that Sean Collins is leading. 5:00 on VLANs and gateways, (and there's a 4:10 session on SR-IOV that's related as well). I think it's hard to move this one. But happy to find a time to meet again tomorrow w/ folks that couldn't make 1:30. Lunch break works for me, what about others? thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
