Apologies for snipping the text. I did it to keep this thread readable. > >Hi Darrell and Jan. >Thanks for looking at this. I agree with Darrell that mixing implementations on >two different levels is a bad idea, but as I already wrote in reply to >Bhanuprakash [2], there is no issues with implementing of output batching of >more than one rx batch. > >[2] https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/334808.html > >Look at the incremental below. This is how it may look like: HI Ilya,
I briefly went through the incremental patch and see that you introduced config parameter to tune the latency and built the logic around it. It may work but we are back to same question. Is dpif layer the right place to do all of this? Shouldn't this logic be part of netdev layer as tx batching rightly belongs to netdev layer. If a specific use case warrants tuning the queuing, flushing and latency parameters let this be done at netdev layer by providing more configs with acceptable defaults and leave the dpif layer simple as it is now. You referred to performance issues with flushing triggered from non-local thread (on different NUMA node). This may be because in lab, we simulate these cases and saturate the 10G link. But this may not be a very pressing issue in real world scenarios. - Bhanuprakash. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
