The only other suggestion I have is that it might be worth using the sFlow-RT "sflow-test" app from time to time as an external test that will only pass if the sFlow agent in OVS is behaving correctly for both counters and packet samples. In addition to the browser UI it has an API that can be queried with curl, so it would be quite possible to script a test that configured OVS, launched a series of iperfs with gaps between, and then read back the results. It would take several minutes (can't use the cunning time-compression trick that other OVS tests use) but it would cover a lot of the things that can go wrong. There is a docker image called "sflow/sflow-test" that you could use. Here is a blog post about it: https://blog.sflow.com/2015/11/sflow-test.html
------ Neil McKee InMon Corp. On Tue, May 28, 2024 at 5:13 AM Ilya Maximets <[email protected]> wrote: > On 5/28/24 13:27, Eelco Chaudron wrote: > > > > > > On 28 May 2024, at 1:04, Neil McKee wrote: > > > >> Would it help if I set up a separate github project for this sFlow > encoding > >> C code? Then we could make it easier to incorporate in OVS by fixing > the > >> whitespace and indentation issues there, and maybe change all the > "time_t" > >> variables to uint32_t to save unnecessary headaches like these. (We > could > >> also shrink it by removing hooks that were only added to support an SNMP > >> control MIB that OVS does not have or need.) > >> > >> The library has evolved only a little since it was copy-pasted into OVS > a > >> while ago, but the latest variant of it is the one that is part of the > >> host-sflow project here: > >> https://github.com/sflow/host-sflow/tree/master/src/sflow > >> This version has a more efficient XDR encoding scheme, and it supports > the > >> new packet-drop-notification extension to sFlow. It would certainly > >> benefit from having the scrutiny of the OVS project brought to bear, so > >> let me know if you think a separate github project would be usable. > >> > >> I don't even know if OVS now uses a "subproject" mechanism or not, so > >> maybe the idea is moot. > > > > Hi Neil, > > > > Thanks for your feedback. Currently, we do not have any git submodules > in OVS, > > and I’m not sure if making a fork of > https://github.com/sflow/host-sflow/, and > > extracting the parts we need, keeping it in sync is the cleanest way > forward. > > > > I assume the cleanest way would be if we could occasionally sync the > files from > > https://github.com/sflow/host-sflow/ without any modifications, but not > sure if > > that is doable within the host-flows project. > > > > Ilya, thoughts? > > > > //Eelco > > Thanks for the offer, Neil! > > I think, from packaging perspective, having sFlow code just be within OVS > is much > more simple option than consuming an external library. And, as you said, > the > original code didn't evolve too much so it's not a big burden to port > changes. > On the other hand, we didn't actually port any changes for a while and OVS > developers > are generally not an sFlow experts, so consuming an external library would > be easier > from that perspective. > > Since it's not a huge amount of code and OVS will still need a decent > amount of > glue to pair with the library as well as maintain OVS-specific counters, I > think, > it's better to keep things as-is for now and try to periodically sync with > the > original code from host-sflow. Sub-projects/modules/trees are generally > not easy > to work with, so I'd like to avoid them, if possible. We do not have any > at the > moment. > > The new XDR encoding looks very nice though, we should definitely port > that! > > Best regards, Ilya Maximets. > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
