Thanks Alex, applied to 'ovn'.
On Tue, Jun 16, 2015 at 11:11:42AM -0700, Alex Wang wrote: > Good to see these done!~ > > Acked-by: Alex Wang <al...@nicira.com> > > On Tue, Jun 16, 2015 at 10:33 AM, Ben Pfaff <b...@nicira.com> wrote: > > > Signed-off-by: Ben Pfaff <b...@nicira.com> > > --- > > ovn/TODO | 85 > > ---------------------------------------------------------------- > > 1 file changed, 85 deletions(-) > > > > diff --git a/ovn/TODO b/ovn/TODO > > index fe296b4..07d66da 100644 > > --- a/ovn/TODO > > +++ b/ovn/TODO > > @@ -1,64 +1,5 @@ > > * ovn-controller > > > > -** Flow table handling in ovn-controller. > > - > > - ovn-controller has to transform logical datapath flows from the > > - database into OpenFlow flows. > > - > > -*** Definition (or choice) of data structure for flows and flow table. > > - > > - It would be natural enough to use "struct flow" and "struct > > - classifier" for this. Maybe that is what we should do. However, > > - "struct classifier" is optimized for searches based on packet > > - headers, whereas all we care about here can be implemented with a > > - hash table. Also, we may want to make it easy to add and remove > > - support for fields without recompiling, which is not possible with > > - "struct flow" or "struct classifier". > > - > > - On the other hand, we may find that it is difficult to decide that > > - two OXM flow matches are identical (to normalize them) without a > > - lot of domain-specific knowledge that is already embedded in struct > > - flow. It's also going to be a pain to come up with a way to make > > - anything other than "struct flow" work with the ofputil_*() > > - functions for encoding and decoding OpenFlow. > > - > > - It's also possible we could use struct flow without struct > > - classifier. > > - > > -*** Translating logical datapath actions into OpenFlow actions. > > - > > - Some of the logical datapath actions do not have natural > > - representations as OpenFlow actions: they require > > - packet-in/packet-out round trips through ovn-controller. The > > - trickiest part of that is going to be making sure that the > > - packet-out resumes the control flow that was broken off by the > > - packet-in. That's tricky; we'll probably have to restrict control > > - flow or add OVS features to make resuming in general possible. Not > > - sure which is better at this point. > > - > > -*** OpenFlow flow table synchronization. > > - > > - The internal representation of the OpenFlow flow table has to be > > - synced across the controller connection to OVS. This probably > > - boils down to the "flow monitoring" feature of OF1.4 which was then > > - made available as a "standard extension" to OF1.3. (OVS hasn't > > - implemented this for OF1.4 yet, but the feature is based on a OVS > > - extension to OF1.0, so it should be straightforward to add it.) > > - > > - We probably need some way to catch cases where OVS and OVN don't > > - see eye-to-eye on what exactly constitutes a flow, so that OVN > > - doesn't waste a lot of CPU time hammering at OVS trying to install > > - something that it's not going to do. > > - > > -*** Logical/physical translation. > > - > > - When a packet comes into the integration bridge, the first stage of > > - processing needs to translate it from a physical to a logical > > - context. When a packet leaves the integration bridge, the final > > - stage of processing needs to translate it back into a physical > > - context. ovn-controller needs to populate the OpenFlow flows > > - tables to do these translations. > > - > > *** Determine how to split logical pipeline across physical nodes. > > > > From the original OVN architecture document: > > @@ -78,8 +19,6 @@ > > The split pipeline processing split will influence how tunnel keys > > are encoded. > > > > -*** Monitor Pipeline table in OVN, trigger flow table recomputation on > > change. > > - > > ** ovn-controller parameters and configuration. > > > > *** SSL configuration. > > @@ -94,13 +33,6 @@ > > > > Andy Zhou is looking at these issues. > > > > -** Scaling number of connections. > > - > > - In typical use today a given ovsdb-server has only a single-digit > > - number of simultaneous connections. The OVN Southbound database will > > - have a connection from every hypervisor. This use case needs testing > > - and probably coding work. Here are some possible improvements. > > - > > *** Reducing amount of data sent to clients. > > > > Currently, whenever a row monitored by a client changes, > > @@ -161,20 +93,3 @@ > > Epstein et al., "What's the Difference? Efficient Set > > Reconciliation Without Prior Context". (I'm not yet aware of > > previous non-academic use of this technique.) > > - > > -* Miscellaneous: > > - > > -** Init scripts for ovn-controller (on HVs), ovn-northd, OVN DB server. > > - > > -** Distribution packaging. > > - > > -* Not yet scoped: > > - > > -** Neutron plugin. > > - > > - This is being developed on OpenStack's development infrastructure > > - to be along side most of the other Neutron plugins. > > - > > - http://git.openstack.org/cgit/openstack/networking-ovn > > - > > -** Gateways. > > -- > > 2.1.3 > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
