> Is this still up-to-date? I know that we've had a lot of discussion and > a couple of patch versions related to netdevs this week.
Yup, this is still up-to-date. I've looked over the netdev code committed in the last week and did a sanity test to make sure everything still works. > have to say that I don't understand the previous paragraph of the > commit message. Maybe you could spell it out more precisely? Also, the > netdev portion of the commit seems to have little to do with the rest, > so I'd be inclined to make it a separate preparatory commit. After re-reading my commit, I totally agree. I'll resubmit the patch split into 2 with a more clear description. Ryan Wilson Member of Technical Staff wr...@vmware.com 3401 Hillview Avenue, Palo Alto, CA 650.427.1511 Office 916.588.7783 Mobile On May 9, 2014, at 9:59 AM, Alex Wang <al...@nicira.com> wrote: > Hey Ben, > > I think this one is up-to-date. I'm reviewing it. > > Your comments make sense. I think Ryan will adjust it. > > Also, I'd also like you or Ethan to review it. > > Thanks, > Alex Wang, > > > On Fri, May 9, 2014 at 8:29 AM, Ben Pfaff <b...@nicira.com> wrote: > Is this still up-to-date? I know that we've had a lot of discussion and > a couple of patch versions related to netdevs this week. > > More below. > > On Tue, May 06, 2014 at 09:54:12AM -0700, Ryan Wilson wrote: > > Before, a global read-write lock protected the ofproto-dpif / > > ofproto-dpif-xlate > > interface. Handler and revalidator threads had to wait while configuration > > was > > being changed. This patch implements RCU locking which allows handlers and > > revalidators to operate while configuration is being updated. > > > > This patch also frees netdev with ovsrcu_postpone. This is because if RCU > > reader threads take a ref to the netdev, the netdev cannot be deleted and > > re-created with different types. > > I have to say that I don't understand the previous paragraph of the > commit message. Maybe you could spell it out more precisely? Also, the > netdev portion of the commit seems to have little to do with the rest, > so I'd be inclined to make it a separate preparatory commit. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
