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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
