1) Ok, I will read up on OFPPS_LIVE, clean up my code and send in an appropriate Patch for BFD support
2) This was mainly a point of discussion that I am curious towards. I am concerned that checking all BFD, OAM, CFM, etc., sequentially may harm the throughput of the function odp_port_is_alive(). Whereas a single flag status up/down (OFPPS_LIVE) may cause synchronization problems if one configures multiple failure mechanisms in parallel. Instead, we might introduce a single byte that equals 0x00 if none of the mechanisms detect downtime. Then we reserve a single bit per mechanism (f.e. 0x01 for administrative port status, 0x02 for OAM/CFM, 0x04 for BFD). Meaning that a non 0x00 value means the port is not live resulting in a single if-statement instead of multiple nested if-statements with double checks on whether given mechanisms are actually configured, etc., and different mechanisms may report up- and downtime without interference by setting there respective bit to 1. Though I realize this requires quite some work. Best, Niels ________________________________________ From: Ben Pfaff [b...@nicira.com] Sent: Friday, August 29, 2014 11:02 PM To: Niels van Adrichem Cc: dev@openvswitch.org Subject: Re: [ovs-dev] BFD integration into FastFailover Group Table On Fri, Aug 29, 2014 at 01:15:53PM +0000, Niels van Adrichem wrote: > For some experiments I did around April/May for a paper I wrote I > changed some sourcecode to ofproto-dpif-xlate.c to have the FastFailover > Group Table look at the BFD status directly. > We did this because we found that although the BFD status flags changed > in time, interface status remained up (which might or might not already > have been solved by now) and hence the FastFailover rule would not > select the backup forwarding rule. Furthermore, our experiments showed > that bringing the interface status down manually could take slightly > over 50 ms before the FastFailover would kick in [1]. As we wanted "even > faster" recovery, we decided to have the function odp_port_is_alive() > also look at the BFD status itself [2]. Doing this also decreased the > number of packets when an interface became live again, as the Fast > Failover rule would not revert sending to the primary rule before BFD > confirmed a live link. > > If you are interested I can rewrite the patch to confirm to the > appropriate coding lay-out and make sure it applies to the current state > of the file. It sounds like a good idea. I am not sure why that function doesn't already check BFD and CFM state. It seems that it should. It also seems that OVS seems to be missing an implementation of OFPPS_LIVE in OpenFlow port state. We should fix that too. > Perhaps instead of checking the BFD status, I could include a > *synchronized* per-interface flag that f.e. equals 0x00 when all > configured link state detection mechanisms detect live links, 0x01 when > BFD detects an error, 0x02 when Ethernet OAM detects an error, 0x03 when > both do, etc. In that case you can check status from multiple detection > mechanisms without the need to iterate through all of them, hence > improving the throughput of OVS. How do you think about that? Code cleanups are always welcome, although I don't entirely understand this proposal. Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
