[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH v2] Introduction of Virtio Network device notifications coalescing feature
> I don't want to > distract you though, I think the virtio-net-level coalescing makes sense > since it counts Ethernet frames rather than virtqueue buffers. I'm not sure it should count ethernet frames, I think that it should count descriptors. Assume the following example: tx-max-frames = 5 The driver wants to send a 64k packet, and VIRTIO_NET_F_HOST_TSO4 is negotiated. The driver will write a 64K description on the descriptor area. The device will segment the payload and will send more than 40 frames (with standard MTU) in a very short time (so the timer is not a factor). The device will send more than 8 notifications to the driver for just 1 used descriptor. I think that speaking of descriptors instead of ethernet frames makes more sense. This is relevant for RX as well. Assume that VIRTIO_NET_F_GUEST_TSO4 is negotiated, and VIRTIO_NET_F_MRG_RXBUF is not. We could receive many frames that will be written in the same descriptor chain, and we are in the same situation as described for TX. I think that this feature should be at a "higher level". The device operates normally, ignoring the coalescing parameters. If the device "decides" that it should send a notification according to VirtIO "rules" (before checking if the events are suppressed by the driver), it will then increase the internal coalescing counters, and decide if it should send the notification. So, in the case of GSO, it will increase the internal tx-fames counter by 1 if the descriptor is of a 64B packet, or a 64KB packet. What do you think?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]