On 5/29/25 11:58 PM, Dmitry Porokh wrote: > > Ilya Maximets <i.maxim...@ovn.org> writes: > >> External email: Use caution opening links or attachments >> >> >> On 5/13/25 9:17 PM, Dmitry Porokh via dev wrote: >>> Introduce two implementations of the jsonrpc >>> input parsing. One "normal" that works as before >>> on the receiver thread. And "threaded" that >>> runs additional thread per each rpc session. >>> >>> In "threaded" case all received data is sent to >>> separate thread to be parsed and result is received >>> on receiver thread as parsed jsons. >>> >>> Motivation for "threaded" version is to free up >>> resources of receiver thread for other processing >>> work. Specifically in ovn / northd json parsing can >>> take from 9% to 30% of all computations. >>> >>> Signed-off-by: Dmitry Porokh <dpor...@nvidia.com> >>> --- >> >> Hi, Dmitry. >> >> nit: This patch should have an "RFC" in the subject prefix, not "PATCH". >> >> While I agree that input json parsing does have impact on performance, it >> feels like there are still many other things that can be optimized in memory >> management and the processing logic before we try to throw more cores on >> the problem. We're trying not to introduce multi-threading unless there is >> absolutely no other way to improve performance in a particular place and >> there is an actual real-world use case where it is necessary. This doesn't >> seem to match the description of the situation with the jsonrpc input >> processing at this time. Multi-threading brings a lot of complexity and >> complicates the logic, which in most cases isn't worth to trade off. >> >> Best regards, Ilya Maximets. > > Hi Ilya, > > I understand concerns related to multi-threading but specifically in this > case threads are completely isolated. Moreover, you need to opt-in to > use thread. By default, single-threaded JSON parsing is used. Also I > confirm that introduction of multithreaded mode breaks some utilities > that create JSON RPC session and then fork another process (threads > are not copied to child process). > > Regardless opinions on threading and should or should not this code be > incorporated to OVS. Does it make sense to create PATCH that separates > JSON parsing from JSON RPC session?
Just moving code around doesn't seem particularly useful in this case. The parser itself is fully separated, moving the data between byteq and the parser is simple enough to not have it's own module. Besides, this may unnecessarily complicate the addition of the time-based batching that Martin and Felix are working on for OVN. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
