search for: head_of_line_blocking

...'t. > And this will make even it harder to figure out > whether zero copy is actually active to diagnose > high cpu utilization cases. Yes. > > > So I think this is a good trick, but let's make > this path conditional on a new debugging module parameter: > how about head_of_line_blocking with default off? Sure. But the head of line blocking was only partially solved in the patch since we only support in-order completion of zerocopy packets. Maybe we need consider switching to out of order completion even for zerocopy skbs? > This way if we suspect packets are delayed forever &g...

...'t. > And this will make even it harder to figure out > whether zero copy is actually active to diagnose > high cpu utilization cases. Yes. > > > So I think this is a good trick, but let's make > this path conditional on a new debugging module parameter: > how about head_of_line_blocking with default off? Sure. But the head of line blocking was only partially solved in the patch since we only support in-order completion of zerocopy packets. Maybe we need consider switching to out of order completion even for zerocopy skbs? > This way if we suspect packets are delayed forever &g...

...ill make even it harder to figure out >> whether zero copy is actually active to diagnose >> high cpu utilization cases. > Yes. >> >> So I think this is a good trick, but let's make >> this path conditional on a new debugging module parameter: >> how about head_of_line_blocking with default off? > Sure. But the head of line blocking was only partially solved in the > patch since we only support in-order completion of zerocopy packets. > Maybe we need consider switching to out of order completion even for > zerocopy skbs? Yan, Dima, I remember that there is a...

...uce the problems with linux guests which don't. And this will make even it harder to figure out whether zero copy is actually active to diagnose high cpu utilization cases. So I think this is a good trick, but let's make this path conditional on a new debugging module parameter: how about head_of_line_blocking with default off? This way if we suspect packets are delayed forever somewhere, we can enable that and see guest networking block. Additionally, I think we should add a way to count zero copy and non zero copy packets. I see two ways to implement this: add tracepoints in vhost-net or add counters...

We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-----+ +-----+ | VM1 | | VM2 | +--+--+

We used to stop the handling of tx when the number of pending DMAs exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation of both host and guest. But it was too aggressive in some cases, since any delay or blocking of a single packet may delay or block the guest transmission. Consider the following setup: +-----+ +-----+ | VM1 | | VM2 | +--+--+