Re: [Qemu-devel] virtio-net: configurable TX queue size

[Wei Wang <wei.w.wang@intel.com>]

On 05/10/2017 05:00 PM, Jason Wang wrote:
>
>
> On 2017年05月07日 12:39, Wang, Wei W wrote:
>> On 05/06/2017 04:37 AM, Michael S. Tsirkin wrote:
>>> On Fri, May 05, 2017 at 10:27:13AM +0800, Jason Wang wrote:
>>>>
>>>> On 2017年05月04日 18:58, Wang, Wei W wrote:
>>>>> Hi,
>>>>>
>>>>> I want to re-open the discussion left long time ago:
>>>>> https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06194.html
>>>>> , and discuss the possibility of changing the hardcoded (256) TX
>>>>> queue size to be configurable between 256 and 1024.
>>>> Yes, I think we probably need this.
>>>>
>>>>> The reason to propose this request is that a severe issue of packet
>>>>> drops in TX direction was observed with the existing hardcoded 256
>>>>> queue size, which causes performance issues for packet drop
>>>>> sensitive guest applications that cannot use indirect descriptor
>>>>> tables. The issue goes away with 1K queue size.
>>>> Do we need even more, what if we find 1K is even not sufficient in the
>>>> future? Modern nics has size up to ~8192.
>>>>
>>>>> The concern mentioned in the previous discussion (please check the
>>>>> link
>>>>> above) is that the number of chained descriptors would exceed
>>>>> UIO_MAXIOV (1024) supported by the Linux.
>>>> We could try to address this limitation but probably need a new
>>>> feature bit to allow more than UIO_MAXIOV sgs.
>>> I'd say we should split the queue size and the sg size.
>>>
>> I think we can just split the iov size in the virtio-net backend,
>> that is, split the large iov[] into multiple iov[1024] to send to 
>> writev.
>>
>> Best,
>> Wei
>
> Maybe, but let's first clarify the limitation and new ability in the 
> spec. Want to send a patch?
>
Hi Jason,

I just posted a new discussion in another email. Please have a check if 
it's possible to solve the
issue from the existing implementation.

Best,
Wei