On Wed, Oct 16, 2013 at 4:07 PM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Oct 16, 2013 at 01:55:41PM -0700, Gurucharan Shetty wrote: >> The new column 'kmod_version' will be used by ovs-ctl to set the >> kernel module version that ovs-vswitchd will be interacting with. >> This column can be quite useful for remote systems to figure out >> any discrepancies in the kernel module version being used in all >> of the hypervisors under its domain. >> >> Signed-off-by: Gurucharan Shetty <gshe...@nicira.com> > > It would be better if we could avoid adding to the database columns > that assume some particular underlying datapath. Right now most of > the OVS installations use the linux kernel datapath, but there are > exceptions already (e.g. FreeBSD/NetBSD and ASICs) and we'll probably > have more in the future (e.g. DPDK integration). > > So to me that points to naming this something more like > "datapath_version", which is a more generic concept. But once we do > that, it should become a per-Bridge concept. And once we get to that > point, we've already got a suitable place to put it, the OFPST_DESC > message handled by handle_desc_stats_request() in ofproto.c. Can we > put datapath-defined info into one of those fields, and for the Linux > datapath supply the module version in it?
I did feel that having the new field in Open_vSwitch table is not correct because of the reasons you pointed out. It feels to me that making it a per-bridge field feels a little odd for a manager that wants to show this as a per hypervisor field where per bridge information is probably a implementation concept. Do you feel it makes sense to set this as part of the system-version field? ex: If the system_version currently says: system_version : "12.04-precise" We will add additional information to it that also included the kernel module version? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
