[ovs-dev] [PATCH] vswitch.ovsschema: A new column, 'kmod_version' in Open_vSwitch table.

Gurucharan Shetty shettyg at nicira.com
Thu Oct 17 15:16:21 UTC 2013


On Wed, Oct 16, 2013 at 4:07 PM, Ben Pfaff <blp at 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 <gshetty at 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?



More information about the dev mailing list