Re: [openstack-dev] [neutron] multiple agents with segment access
> -Original Message- > From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] > Sent: Tuesday, November 14, 2017 4:19 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] multiple agents with segment access > > In general, you should be able to run both regular l2 agent (ovs) and sriov > agent. If you have problems with it, we should probably assume it's a bug. > Please report. Ok, since this affects two distinct parts of the system I created 2 separate bug reports: https://bugs.launchpad.net/neutron/+bug/1732445 https://bugs.launchpad.net/neutron/+bug/1732448 __ 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-dev] [neutron] multiple agents with segment access
Is it a known limitation that the ML2 plugin and associated drivers do not properly handle cases where there are multiple agents running on the same host? That is, two or more agents that reside on the same host and both report device/interface mappings for physical networks?One such setup is a set of nodes that are both running an L2 agent and a NIC SRIOV agent. We have found two problems specific to this configuration and are wondering if these are known limitations, or simply not supported. For example, in a configuration where a host has L2, DHCP, and SRIOV agents running on it, then: 1) The DHCP scheduler can schedule a network to be hosted by that DHCP agent even if the physical network is only supported by the SRIOV agent and not by the L2 agent. This can end up isolating the DHCP server as it will not have access to the underlying physical segment. This is happening because "filter_hosts_with_network_access" in the Ml2Plugin will include the host because the SRIOV mech driver reports that it has access to that segment. 2) The Segment Plugin "segmenthostmappings" table gets overwritten with tuples for whichever agent reports in last. For example, if the L2 agent has physical network mappings for 2 different physical networks (physnet0, physnet1), but the SRIOV NIC agent only has 1 physical network reported (physnet2), the segmenthostmappings table will have data for only physnet2 if the SRIOV NIC agent reported last, or data for only both physnet0 and physnet1 if the L2 agent reported last. Data for physical networks belonging to the other agent will be erroneously removed as stale entries. If it has been discussed before is there a plan to address this type of configuration? Regards. Allain Allain Legacy, Software Developer, Wind River direct 613.270.2279 fax 613.492.7870 skype allain.legacy 350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5 __ 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] [oslo][concurrency] lockutils lock fairness / starvation
> -Original Message- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: Monday, May 15, 2017 2:55 PM <...> > > Excerpts from Legacy, Allain's message of 2017-05-15 18:35:58 +: > > import eventlet > > eventlet.monkey_patch > > That's not calling monkey_patch -- there are no '()'. Is that a typo? Yes, sorry, that was a typo when I put it in to the email. It did have () at the end. > > lock() claims to work differently when monkey_patch() has been called. > Without doing the monkey patching, I would expect the thread to have to > explicitly yield control. > > Did you see the problem you describe in production code, or just in this > sample program? We see this in production code. I included the example to boil this down to a simple enough scenario to be understood in this forum without the distraction of superfluous code. __ 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-dev] [oslo][concurrency] lockutils lock fairness / starvation
Can someone comment on whether the following scenario has been discussed
before or whether this is viewed by the community as a bug?
While debugging a couple of different issues our investigation has lead
us down the path of needing to look at whether the oslo concurrency lock
utilities are working properly or not. What we found is that it is
possible for a greenthread to continuously acquire a lock even though
there are other threads queued up waiting for the lock.
For instance, a greenthread acquires a lock, does some work, releases
the lock, and then needs to repeat this process over several iterations.
While the first greenthread holds the lock other greenthreads come along and
attempt to acquire the lock. Those subsequent greenthreads are added to the
waiters list and suspended. The observed behavior is that as long as the
first greenthread continues to run without ever yielding it will always
re-acquire the lock even before any of the waiters.
To illustrate my point I have included a short program that shows the
effect of multiple threads contending for a lock with and without
voluntarily yielding. The code follows, but the output from both
sample runs are included here first.
In both examples the output is formatted as "worker=XXX: YYY" where XXX
is the worker number, and YYY is the number of times the worker has been
executed while holding the lock.
In the first example, notice that each worker gets to finish all of its
tasks before any subsequence works gets to run even once.
In the second example, notice that the workload is fair and each worker
gets to hold the lock once before passing it on to the next in line.
Example1 (without voluntarily yielding):
=
worker=0: 1
worker=0: 2
worker=0: 3
worker=0: 4
worker=1: 1
worker=1: 2
worker=1: 3
worker=1: 4
worker=2: 1
worker=2: 2
worker=2: 3
worker=2: 4
worker=3: 1
worker=3: 2
worker=3: 3
worker=3: 4
Example2 (with voluntarily yielding):
=
worker=0: 1
worker=1: 1
worker=2: 1
worker=3: 1
worker=0: 2
worker=1: 2
worker=2: 2
worker=3: 2
worker=0: 3
worker=1: 3
worker=2: 3
worker=3: 3
worker=0: 4
worker=1: 4
worker=2: 4
worker=3: 4
Code:
=
import eventlet
eventlet.monkey_patch
from oslo_concurrency import lockutils
workers = {}
synchronized = lockutils.synchronized_with_prefix('foo')
@synchronized('bar')
def do_work(index):
global workers
workers[index] = workers.get(index, 0) + 1
print "worker=%s: %s" % (index, workers[index])
def worker(index, nb_jobs, sleep):
for x in xrange(0, nb_jobs):
do_work(index)
if sleep:
eventlet.greenthread.sleep(0) # yield
return index
# hold the lock before starting workers to make sure that all worker queue up
# on the lock before any of them actually get to run.
@synchronized('bar')
def start_work(pool, nb_workers=4, nb_jobs=4, sleep=False):
for i in xrange(0, nb_workers):
pool.spawn(worker, i, nb_jobs, sleep)
print "Example1: sleep=False"
workers = {}
pool = eventlet.greenpool.GreenPool()
start_work(pool)
pool.waitall()
print "Example2: sleep=True"
workers = {}
pool = eventlet.greenpool.GreenPool()
start_work(pool, sleep=True)
pool.waitall()
Regards,
Allain
Allain Legacy, Software Developer, Wind River
direct 613.270.2279 fax 613.492.7870 skype allain.legacy
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5
__
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
