<div dir="ltr"><div><div><div><div><div><div>Hi, sorry for the late reply, I was out of office for 3 weeks.<br><br>I also love the idea of having a single thread in charge of writing dataplane actions.<br></div>As Zang described, this thread would read events in a queue, which could be populated by agent_drivers.<br>
</div>The main goal would be to avoid desynchronization. While a first greenthread can yield while performing a dataplane action (for instance, running a ofctl command) another greenthread could potentially process another action that should be done after the first one is terminated.<br>
</div>enqueuing those actions and processing them in a single thread would avoid such a behavior.<br><br></div>I also think this is orthogonal with the agent/resource architecture. I think that agent driver could populate the queue, and the singleton thread would call the correct resource driver, depending on the impacted port, to interpret the order filed in the queue.<br>
<br></div>regards <br></div>Mathieu<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 10:38 PM, Mohammad Banikazemi <span dir="ltr"><<a href="mailto:mb@us.ibm.com" target="_blank">mb@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p><font face="sans-serif">Zang, thanks for your comments.</font><br>
<br>
<font face="sans-serif">I think what you are suggesting is perhaps orthogonal to having Resource and Agent drivers. By that I mean we can have what you are suggesting and keep the Resource and Agent drivers. The reason for having Resource drivers is to provide the means for possibly extending what an agent does in response to say changes to a port in a modular way. We can restrict the access to Resource drivers from the events loop only. That restriction is not there in the current model but would adding that address your concerns? What are your thoughts? As Salvatore has mentioned in his email in this thread, that is what the current OVS agent does wrt port updates. That is, the update to ports get processed from the events loop.</font><br>
<br>
<font face="sans-serif">As a separate but relevant issue, we can and should discuss whether having the Resource and Agent drivers is useful in making the agent more modular. The idea behind using these drivers is to have the agent use a collection of drivers rather than mixin classes so we can more easily select what (and how) functionalities an agent support and reuse as much as we can across L2 agents. Are there better ways of achieving this? Any thoughts?</font><br>
<br>
<font face="sans-serif">Best,</font><br>
<br>
<font face="sans-serif">Mohammad</font><br>
<br>
<br>
<br>
<img src="cid:1__=0ABBF66EDFFDD6528f9e8a93df938@us.ibm.com" alt="Inactive hide details for Zang MingJie ---06/19/2014 06:27:31 AM---Hi: I don't like the idea of ResourceDriver and AgentDriver." height="16" width="16" border="0"><font color="#424282" face="sans-serif">Zang MingJie ---06/19/2014 06:27:31 AM---Hi: I don't like the idea of ResourceDriver and AgentDriver. I suggested</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Zang MingJie <<a href="mailto:zealot0630@gmail.com" target="_blank">zealot0630@gmail.com</a>></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">06/19/2014 06:27 AM</font></p><div class=""><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture</font><br>
</div><hr style="color:#8091a5" noshade size="2" width="100%" align="left"><div><div class="h5"><br>
<br>
<br>
<tt><font>Hi:<br>
<br>
I don't like the idea of ResourceDriver and AgentDriver. I suggested<br>
use a singleton worker thread to manager all underlying setup, so the<br>
driver should do nothing other than fire a update event to the worker.<br>
<br>
The worker thread may looks like this one:<br>
<br>
# the only variable store all local state which survives between<br>
different events, including lvm, fdb or whatever<br>
state = {}<br>
<br>
# loop forever<br>
while True:<br>
event = ev_queue.pop()<br>
if not event:<br>
sleep() # may be interrupted when new event comes<br>
continue<br>
<br>
origin_state = state<br>
new_state = event.merge_state(state)<br>
<br>
if event.is_ovsdb_changed():<br>
if event.is_tunnel_changed():<br>
setup_tunnel(new_state, old_state, event)<br>
if event.is_port_tags_changed():<br>
setup_port_tags(new_state, old_state, event)<br>
<br>
if event.is_flow_changed():<br>
if event.is_flow_table_1_changed():<br>
setup_flow_table_1(new_state, old_state, event)<br>
if event.is_flow_table_2_changed():<br>
setup_flow_table_2(new_state, old_state, event)<br>
if event.is_flow_table_3_changed():<br>
setup_flow_table_3(new_state, old_state, event)<br>
if event.is_flow_table_4_changed():<br>
setup_flow_table_4(new_state, old_state, event)<br>
<br>
if event.is_iptable_changed():<br>
if event.is_iptable_nat_changed():<br>
setup_iptable_nat(new_state, old_state, event)<br>
if event.is_iptable_filter_changed():<br>
setup_iptable_filter(new_state, old_state, event)<br>
<br>
state = new_state<br>
<br>
when any part has been changed by a event, the corresponding setup_xxx<br>
function rebuild the whole part, then use the restore like<br>
`iptables-restore` or `ovs-ofctl replace-flows` to reset the whole<br>
part.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><tt><font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font><br>
<br>
</font></tt><br>
</div></div><p></p></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>