[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle
hdaniel at redhat.com
Thu May 26 12:42:27 UTC 2016
sorry for digging up this thread. I took a liberty to submitt an RFE per
Ihar's suggestion for the first step (switching to l2 agent extensions):
As a followup on that - hoping to send some wip patches in the near time.
Hope to hear your thoughts/suggestions on the $subj.
On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
>> I think there is no formal spec or anything, just some emails around
>> That said, I don’t follow why it’s a requirement for SFC to switch to l2
>> agent extension mechanism. Even today, with SFC maintaining its own agent,
>> there are no clear guarantees for flow priorities that would avoid all
>> possible conflicts.
>> Cathy> There is no requirement for SFC to switch. My understanding is
>> that current L2 agent extension does not solve the conflicting entry issue
>> if two features inject the same priority table entry. I think this new L2
>> agent effort is try to come up with a mechanism to resolve this issue. Of
>> course if each feature( SFC or Qos) uses its own agent, then there is no
>> coordination and no way to avoid conflicts.
> Sorry, I probably used misleading wording. I meant, why do we consider the
> semantic flow management support in l2 agent extension framework a
> *prerequisite* for SFC to switch to l2 agent extensions? The existing
> framework should already allow SFC to achieve what you have in the
> subproject tree implemented as a separate agent (essentially a fork of OVS
> agent). It will also set SFC to use standard extension mechanisms instead
> of hacky inheritance from OVS agent classes. So even without the strict
> semantic flow management, there is benefit for the subproject.
> With that in mind, I would split this job into 3 pieces:
> * first, adopt l2 agent extension mechanism for SFC functionality
> (dropping custom agent);
> * then, work on semantic flow management support in OVS agent API class
> * once the feature emerges, switch SFC l2 agent extension to the new
> framework to manage SFC flows.
> I would at least prioritize the first point and target it to Newton-1.
> Other bullet points may take significant time to bake.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev