similar to: Question about disabling UFO on guest

Hi Michal, What I found was that when I restarted the machine and did a virsh edit command to see the xml config, I see that it is was not actually changed. This suggests why I saw 256 again after restarting. So now I tried again to edit the xml via virsh edit command and used the following to set the parameters. <driver name='qemu' txmode='iothread' ioeventfd='on'

Hi Ashish, I have tested with your xml in the first mail, and it works for rx_queue_size(see below). multiqueue need to work with vhost backend driver. And when you set "queues=1" it will ignored. Please check your qemu-kvm-rhev package, should be newer than qemu-kvm-rhev-2.9.0-16.el7_4.2 And the logs? tx_queue_size='512' will not work in the guest with direct type interface,

Hi Ashish, IMO, it is yes, no way to increase tx_queue_size for direct type interface ------- Best Regards, Yalan Zhang IRC: yalzhang Internal phone: 8389413 On Thu, Oct 26, 2017 at 3:38 PM, Ashish Kurian <ashishbnv@gmail.com> wrote: > Hi Yalan, > > In the previous email you mentioned "tx_queue_size='512' will not work in > the guest with direct type

Dear Users/Developers, I am using a KVM Ubuntu VM as a degrader to apply specific delays to incoming packets. As the delay for my packets can be higher than 7.5 seconds, there is not enough buffer on my interface to buffer all the packets. Therefore those overflowing packets are dropped in the machine and not forwarded. When I tried to use the command ethtool -G ens8 rx 512 to increase the

Is there a setting to allow/disable spoof checking and trust on VF from SR-IOV device? Lookin at https://www.libvirt.org/formatdomain.html#elementsDriverBackendOptions can this be done through the driver element? *<driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off' queues='5' rx_queue_size='256' tx_queue_size='256'>

On 10/26/2017 10:38 AM, Ashish Kurian wrote: > Hi Yalan and Michal, > > Thank you for your response. So what I understand is that I can change > rx_queue size even if I use direct type interface and qemu driver as long > as the driver is virtio. Am I right? Yes. > If that is the case why am I getting > the error saying that > > error: XML document failed to validate

Hi Yalan, Thank you for your response. I do not have the following packages installed vhost backend driver qemu-kvm-rhev package Are these packages available for free? How can I install them? In my KVM VM, I must have an IP address to the interfaces that I am trying to increasing the buffers. That is the reason I was using macvtap (direct type interface). Is it possible to have my interfaces

Hi Yalan and Michal, Thank you for your response. So what I understand is that I can change rx_queue size even if I use direct type interface and qemu driver as long as the driver is virtio. Am I right? If that is the case why am I getting the error saying that error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Extra

Hi Yalan, In the previous email you mentioned "tx_queue_size='512' will not work in the guest with direct type interface, in fact, no matter what you set, it will not work and guest will get the default '256'. " So if I am using macvtap for my interfaces, then the device type will always be direct type. Does it mean that there is no way I can increase the buffer size

Hi Michal, An update to what I have already said : when I try adding <driver name='qemu' txmode='iothread' ioeventfd='on' event_idx='off' queues='1' rx_queue_size='512' tx_queue_size='512'> although it showed me the error as mentioned, when I checked the xml again I saw that <driver name='qemu' txmode='iothread'

On 10/25/2017 01:53 PM, Ashish Kurian wrote: > Dear Users/Developers, > > I am using a KVM Ubuntu VM as a degrader to apply specific delays to > incoming packets. As the delay for my packets can be higher than 7.5 > seconds, there is not enough buffer on my interface to buffer all the > packets. Therefore those overflowing packets are dropped in the machine and > not

Hi Michal, Mine is iplab@iceman:~$ libvirtd --version libvirtd (libvirt) 1.3.1 I think this can be the issue. I will update and try again Best Regards, Ashish Kurian On Thu, Oct 26, 2017 at 10:46 AM, Michal Privoznik <mprivozn@redhat.com> wrote: > On 10/26/2017 10:38 AM, Ashish Kurian wrote: > > Hi Yalan and Michal, > > > > Thank you for your response. So what I

Hi Michal, I installed the latest version from the git and did run the libvirt from the new directory using /home/to/your/checkout/daemon/libvirtd But I still see that the version is 1.3.1. I have also stopped the already running libvirt daemon and ran the new daemon from the directory and it is showing 1.3.1 Best Regards, Ashish Kurian On Thu, Oct 26, 2017 at 10:50 AM, Ashish Kurian

On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > Now that UFO is split into v4 and v6 parts, we can bring > back v4 support. Continue to handle legacy applications > by selecting the ipv6 fagment id but do not change the > gso type. This allows 2 legacy VMs to continue to communicate. > > Based on original work from Ben Hutchings. > > Fixes:

On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > Now that UFO is split into v4 and v6 parts, we can bring > back v4 support. Continue to handle legacy applications > by selecting the ipv6 fagment id but do not change the > gso type. This allows 2 legacy VMs to continue to communicate. > > Based on original work from Ben Hutchings. > > Fixes:

On Wed, Dec 17, 2014 at 09:43:51PM -0500, Vlad Yasevich wrote: > On 12/17/2014 05:41 PM, Michael S. Tsirkin wrote: > > On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > >> Now that UFO is split into v4 and v6 parts, we can bring > >> back v4 support. Continue to handle legacy applications > >> by selecting the ipv6 fagment id but do not

On Wed, Dec 17, 2014 at 09:43:51PM -0500, Vlad Yasevich wrote: > On 12/17/2014 05:41 PM, Michael S. Tsirkin wrote: > > On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > >> Now that UFO is split into v4 and v6 parts, we can bring > >> back v4 support. Continue to handle legacy applications > >> by selecting the ipv6 fagment id but do not

In my Linux VM, I am unable to change scatter-gather / tx-checksumming / TCP-segmentation offload features by ethtool command. I am using virtio nic with vhostuser port backend. It shows me an error: Cannot change tx-checksumming Cannot change scatter-gather Cannot change tcp-segmentation offload Could not change any device features Ony running command ethtool -k ens3, I get the following:

Hi, This series allows QEMU to use vhost with legacy virtio devices when host and target don't have the same endianness. Only network devices are covered for the moment. I had already posted a series some monthes ago but it never got reviewed. Moreover, the underlying kernel support was entirely re-written and is still waiting to be applied by Michael. I hence post as RFC. The corresponding

Hi, This series allows QEMU to use vhost with legacy virtio devices when host and target don't have the same endianness. Only network devices are covered for the moment. I had already posted a series some monthes ago but it never got reviewed. Moreover, the underlying kernel support was entirely re-written and is still waiting to be applied by Michael. I hence post as RFC. The corresponding