On Fri, Dec 26, 2025 at 3:19 PM Zhang Chen <[email protected]> wrote: > > On Fri, Dec 26, 2025 at 2:30 PM Jason Wang <[email protected]> wrote: > > > > On Fri, Dec 26, 2025 at 2:26 PM Jason Wang <[email protected]> wrote: > > > > > > On Fri, Dec 26, 2025 at 11:15 AM Zhang Chen <[email protected]> wrote: > > > > > > > > On Fri, Dec 26, 2025 at 9:37 AM Jason Wang <[email protected]> wrote: > > > > > > > > > > On Thu, Dec 25, 2025 at 6:27 PM Zhang Chen <[email protected]> > > > > > wrote: > > > > > > > > > > > > On Thu, Dec 25, 2025 at 3:24 PM Jason Wang <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > Add test_change_interval_timer to verify that modifying the > > > > > > > 'interval' > > > > > > > property of filter-buffer at runtime takes effect immediately. > > > > > > > > > > > > > > The test uses socket backend and filter-redirector to verify > > > > > > > timer behavior: > > > > > > > - Creates filter-buffer with a very long interval (1000 seconds) > > > > > > > - Sends a packet which gets buffered > > > > > > > - Advances virtual clock by 1 second, verifies packet is still > > > > > > > buffered > > > > > > > - Changes interval to 1ms via qom-set (timer should be > > > > > > > rescheduled) > > > > > > > - Advances virtual clock by 2ms, verifies packet is now released > > > > > > > - This proves the timer was rescheduled immediately when interval > > > > > > > changed > > > > > > > > > > > > > > The test uses filter-redirector to observe when packets are > > > > > > > released > > > > > > > by filter-buffer, providing end-to-end verification of the timer > > > > > > > rescheduling behavior. > > > > > > > > > > > > If user try to simulate network latency by filter-buffer, the > > > > > > accuracy > > > > > > of time is important. > > > > > > Do we need add some note about the first buffered packet time not > > > > > > equel to dynamic > > > > > > changed time (default interval time - new qmp cmd effected time + > > > > > > changed time ?). > > > > > > > > > > I'm not sure I will get here, we can't forcast when the first packet > > > > > will come. So the behaviour is always that the filter-buffer will > > > > > flush at a fixed interval. Or I may miss something here. > > > > > > > > This case same like this test, before change the user target interval > > > > time, > > > > filter-buffer maybe already buffered lots of packets, for this parts, > > > > the user > > > > external measured time did not meet the expected settings. > > > > > > There's indeed a change of the behaviour, but I'm not sure if there's > > > a user that depends on the previous behaviour. > > > > > > Or if we really care, we need a new attribute. > > > > Btw, the use case is something like these (out of the scope of COLO). > > > > Mgmt want to buffer the packets for a while and release the buffered > > packets immediately when something happens. > > Yes, I know that. And back to COLO, do you think we should change the > colo-compare module > to a general network comparision module? Any comments about it?
I don't see how colo-compare could be used out of the scope of COLO, but I do see buffer, mirror and redirector can. Going back to this patch, are you ok with this or expect something else Thanks > > Thanks > Chen > > > > > Thanks > > >
