WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] ring buffer overflow

Please don't top post.

On Tue, 2011-10-04 at 16:17 +0100, David Xu wrote:
> Hi,
> 
> I made the experiment with httperf again, and used tcpdump to capture
> the packets on both server side and client side. I found that if there
> was some retransmission (e.t. client send several syn to server
> because it didn't receive ack in time), the vif only receive the last
> packet (syn) and missed the former ones. So I think there are some
> issues happened between the eth0(veth0) and vif in the dom0. But if I
> use a low latency scheduler written by myself (only modify the client
> scheduler and didn't touch other parts ), there will not be
> retransmission or there is very few retransmission. I am not familiar
> with netback of xen. Can you give me some suggestion? Or which part
> source code I need to check to find the reason of packets loss between
> eth0(veth0) and vif in dom0? Thanks.

The netback code lives in either drivers/xen/netback or
drivers/net/xen-netback depending on the kernel you are using. The
interesting code is generally split between netback.c and interface.c.

>From the point of view of the kernel it is just a normal network driver.
For packets going from dom0->domU you can look at the .ndo_start_xmit
callback registered with the kernel (xenvif_start_xmit in mainline,
something else in some other kernels) and trace from there to see how
and where they can be dropped.

For packets coming the other way (domU->dom0) you can either start from
the place which calls netif_rx_ni() and work backwards or start from the
interrupt handler, i.e. the function passed to
bind_interdomain_evtchn_to_irqhandler() and work forwards.

You might also find starting from the *_tx_action and *_rx_action
functions useful starting points for tracing what is going on..

Ian.

> 
> Regards,
> Cong
> 
> 2011/9/30 Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>:
> > On Fri, 2011-09-30 at 15:44 +0100, David Xu wrote:
> >> Hi,
> >>
> >> 2011/9/29 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> >> > On Fri, 2011-09-30 at 05:18 +0100, David Xu wrote:
> >> >> Hi,
> >> >>
> >> >> Does anybody know whether the ring buffer between front end and back
> >> >> end will suffer from overflow? I just wonder if the ring buffer will
> >> >> be full and drop some packets when the Net I/O load is very heavy.
> >> >
> >> > In the case of networking whichever end is putting stuff on the ring
> >> > checks that there is enough room and will stop the queue when it cannot
> >> > transmit any more and restart when room becomes available.
> >>
> >> You mean even there is not enough room in ring buffer, xen will * not
> >> drop the packets * and just delay the transmission.
> >
> > It's not Xen but rather the kernel back and front ends which is involved
> > here. You can examine the hard_start_xmit functions in both netback and
> > netfront to determine for yourself whether or not packets can be dropped
> > and when.
> >
> >>  I used httperf to
> >> measure the performance of web server running in a VM (The workload in
> >> this VM is mixed, so it can not benefit from boost mechanism. The net
> >> i/o suffers from relatively high latency which depends on the number
> >> of VMs in the system). I found that with the increase of request rate
> >> in client side, the connection rate will drop and the connection time
> >> will increase dramatically. And the retransmission appears when the
> >> request rate is over than a quantum. So I doubted that the http/tcp
> >> connection suffer from the packets drop when the ring buffer is full
> >> because of high request rate.
> >>
> >> >
> >> >> BTW, If I want to change the size of i/o ring buffer, how should I do?
> >> >> I tried to reset the NET_TX_RING_SIZE and NET_RX_RING_SIZE in both
> >> >> front end and back end, but it seems doesn't work. Thanks.
> >> >
> >> > Currently the rings are limited to 1 page so if you want to increase the
> >> > size you would need to add multipage ring support to the network
> >> > protocol. There have been patches to do this for the blk protocol but I
> >> > do not recall any for the net protocol.
> >>
> >> Yes, increasing the size is relatively hard. So I just want reduce the
> >> size of ring buffer to make sure my doubt described above. I directly
> >> set  NET_TX_RING_SIZE and  NET_RX_RING_SIZE to 128, but it doesn't seem to 
> >> work.
> >
> > You need to make sure both ends of the connection agree on the ring
> > size.
> >
> > I'm afraid this is not a very common thing to want to do so if you want
> > to persist with this approach I'm afraid you'll have to do some
> > debugging.
> >
> > Ian.
> >
> >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel