On Tue, Jul 23, 2013 at 11:27 AM, Ben Pfaff <b...@nicira.com> wrote: > On Mon, Jul 22, 2013 at 12:17:06PM -0700, Gurucharan Shetty wrote: > > Current situation is that CAP_NETWORK_STATUS has a max size of 50 MB. > > When we have around 100,000 openflow flows, we over-run that size > > by just running the "ovs-ofctl dump-flows" command. All the openvswitch > > commands run through the plugin scripts in this repo won't have its > > data stored in the debug bundle in this case as they are part of > > CAP_NETWORK_STATUS too. One option to correct this is to increase > > the CAP_NETWORK_STATUS max size to a higher number. But > CAP_NETWORK_STATUS > > also includes a bunch of general network related information collected > > by running commands like ethtool, tc etc. and we probably want to limit > > the data collected through those commands. > > > > With this commit, we create a new capability called CAP_NETWORK_INFO > > and collect general network related information through them. For OVS > > related information, we continue to use CAP_NETWORK_STATUS, but remove > > the maximum size restriction. One rationale to keep OVS related > > information in CAP_NETWORK_STATUS is because xen-bugtool probably expects > > OVS information in that capability. > > > > Signed-off-by: Gurucharan Shetty <gshe...@nicira.com> > > The split seems reasonable. But I am not sure that the names are > good, because I'm not sure I know the difference between "info" and > "status". Did you try to think of more descriptive names? >
I wanted to keep the openvswitch related commands in a new capability called CAP_OPENVSWITCH_STATUS. But as of now, most of the openvswitch commands are run through plugins and we keep it in a directory called "network-status" and that relates to CAP_NETWORK_STATUS. I could have just renamed the plugin directory to"openvswitch-status" and added a xml file to define the capability. But when xen-bugtool is run it will now have all the openvswitch related information in this new capability that is probably unknown for xenserver users. So to keep that compatibility, I let them remain in CAP_NETWORK_STATUS. For the new CAP_NETWORK_INFO, I thought about CAP_LINUXNET_INFO, but some of these utilities are probably there in other platforms too. But I agree that a new name here can probably be more descriptive. If you have any suggestions, I will use them. Thanks, Guru
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
