Sorry Ethan, I saw this right after I posted the patch... ;(
On Wed, Aug 14, 2013 at 7:26 PM, Ethan Jackson <[email protected]> wrote: > In practice users effectively run only one type of datapath. You > aren't going to have production switches which are running both the > linux kernel and the linux userspace datapath for example. If someone > is odd enough to do that, they'll end up with twice as many worker > threads as they expected, which doesn't seem like much of a problem to > me. For this reason I think the simplest thing to do is keep the > configuration parameter in the Open vSwitch table as originally > planned. Perhaps we should document in the database man page that the > n_workers configuration is per datapath not global to the switch. I see, I think it is okay. > > So, it is not appropriate to use a vsctl command. Instead, I'd like to > > implement it as a "appctl dpif/set-n-handler-threads" command. > > The problem with this is ovs-appctl settings are persisted in the > database, so they're reset whenever the switch is restarted (on system > boot or upgrade for example). I expect that most users will have some > prefered number of threads which they want to set once in the database > and then forget about. appctl is a bit of a pain for that. > I agree with your point about persistence. But it seems to me, ofproto-dpif-upcall is not a generic feature. is it reasonable to define a function in ofproto_class?
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
