similar to: [PATCH 1/2] [BUG 183] NETFRONT: Use per-interface grant_{tx, rx}_ref

In netfront, the current driver reserves pools of grant refs for the tx and rx paths, each big enough to satisfy one virtual nic. With more than one nic active you will run out. Both the tx and rx path will BUG() when you do. This patch creates separate tx and rx ref pools for each interface. Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim

Another checksum offload problem was reported on xen-users, when using a domU as a firewall: http://lists.xensource.com/archives/html/xen-users/2006-04/msg01150.html It also fails without VLANs. The path from dom0->domU with ip_summed==CHECKSUM_HW/proto_csum_blank==1 is broken. - skb_checksum_setup() assumes that a checksum will definitely be calculated in dev_queue_xmit(), but the

On Thu, Aug 02, 2018 at 02:04:12PM -0700, Nambiar, Amritha wrote: > On 8/1/2018 5:11 PM, Andrei Vagin wrote: > > On Tue, Jul 10, 2018 at 07:28:49PM -0700, Nambiar, Amritha wrote: > >> With this patch series, I introduced static_key for XPS maps > >> (xps_needed), so static_key_slow_inc() is used to switch branches. The > >> definition of static_key_slow_inc()

On Fri, Aug 03, 2018 at 12:06:51PM -0700, Andrei Vagin wrote: > On Fri, Aug 03, 2018 at 12:08:05AM +0300, Michael S. Tsirkin wrote: > > On Thu, Aug 02, 2018 at 02:04:12PM -0700, Nambiar, Amritha wrote: > > > On 8/1/2018 5:11 PM, Andrei Vagin wrote: > > > > On Tue, Jul 10, 2018 at 07:28:49PM -0700, Nambiar, Amritha wrote: > > > >> With this patch series,

Hi, We are running into a situation where rsp_prod index in the shared ring is not getting updated for the netfront tx ring by the netback. We see that rsp_cons is the same value as rsp_prod, with req_prod 236 slots away(tx ring is full). From looking at the netfront driver code, it looks as if xennet_tx_buf_gc processing only happens if rsp_prod is more than rsp_cons. Our

Hi, We are running into a situation where rsp_prod index in the shared ring is not getting updated for the netfront tx ring by the netback. We see that rsp_cons is the same value as rsp_prod, with req_prod 236 slots away(tx ring is full). From looking at the netfront driver code, it looks as if xennet_tx_buf_gc processing only happens if rsp_prod is more than rsp_cons. Our

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

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'

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

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, it seems as if it is not possible to have more than 3 nics per domU right now. If I specify more, I get the usual [...] xen_net: Initialising virtual ethernet driver. #### netfront can''t alloc rx grant refs vif: probe of vif-3 failed with error -12 [...] message - see bug #183. It was pointed out to me that it might be possible to adjust this manually in

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, 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, I did not find any hints in the web where to configure/setup/manipulate the rx/tx ring buffer allocation within dom0 for xen-unstable, maybe someone here can nudge me towards the right knob. The problem: when booting a handful of domUs and connecting them (comprising a small experimental IP network with links and nodes etc.), some interfaces that have been given by the configuration files

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 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'

This patch adds a new feature called feature-split-event-channels for netfront, enabling it to handle TX and RX events separately. If netback does not support this feature, it falls back to use single event channel. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> --- drivers/net/xen-netfront.c | 173

Hi everybody, i need someone to tell me the spins numbers of Rx+,Rx-,Tx+ and Tx- of TE110P and also if you can tell me have to made a cable like that?? Modem Teleco <-----------Self Crosscable------------>Asterisk Rx+ <--------------------------------------------------------------> Tx+ Rx- <--------------------------------------------------------------> Tx- Tx+