On Fri, Nov 22, 2013 at 10:41:18AM -0800, Joe Stringer wrote:
> On 20 November 2013 11:15, Ben Pfaff wrote:
> >> NB: I'm tracking STP changes in ofproto_port_set_state(), as the testsuite
> >> would fail when I tracked them in stp_set_port_state(). The latter makes
> >> more
> >> sense to me, but
On 20 November 2013 11:15, Ben Pfaff wrote:
>> NB: I'm tracking STP changes in ofproto_port_set_state(), as the testsuite
>> would fail when I tracked them in stp_set_port_state(). The latter makes more
>> sense to me, but I clearly don't understand some interaction there because it
>> makes STP s
Maybe a new file in lib.
On Thu, Nov 21, 2013 at 11:33:04AM -0800, Joe Stringer wrote:
> Do you have any preference for where this lives?
>
> On 20 November 2013 14:45, Ben Pfaff wrote:
> > On Wed, Nov 20, 2013 at 01:50:42PM -0800, Joe Stringer wrote:
> >> On 20 November 2013 11:15, Ben Pfaff w
Do you have any preference for where this lives?
On 20 November 2013 14:45, Ben Pfaff wrote:
> On Wed, Nov 20, 2013 at 01:50:42PM -0800, Joe Stringer wrote:
>> On 20 November 2013 11:15, Ben Pfaff wrote:
>> > I think that it is a little surprising to use a netdev sequence number
>> > to track ch
On Wed, Nov 20, 2013 at 01:50:42PM -0800, Joe Stringer wrote:
> On 20 November 2013 11:15, Ben Pfaff wrote:
> > I think that it is a little surprising to use a netdev sequence number
> > to track changes to things that are not network devices. If we are
> > going to do that, then I think we need
On 20 November 2013 11:15, Ben Pfaff wrote:
> I think that this introduces a strict but easy to miss dependency on the
> order in which ofproto_run() calls the provider's 'run' function and
> that it updates the ofproto's change_seq: it works with the current
> order but if the order were reversed
On Thu, Nov 14, 2013 at 03:28:26PM -0800, Joe Stringer wrote:
> Currently, as part of ofproto-dpif run() processing, we loop through all
> ports and poll corresponding devices for changes in carrier, cfm and bfd
> status. This allows us to determine how it may affect bundles. For the
> average case
Currently, as part of ofproto-dpif run() processing, we loop through all
ports and poll corresponding devices for changes in carrier, cfm and bfd
status. This allows us to determine how it may affect bundles. For the
average case where devices are not going up or down constantly, this is
a large am
