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

[Xen-devel] Re: [Qemu-devel] Re: qemu/rtl8139: Max transmit frame size

To: qemu-devel@xxxxxxxxxx
Subject: [Xen-devel] Re: [Qemu-devel] Re: qemu/rtl8139: Max transmit frame size
From: "Igor Kovalenko" <igor.v.kovalenko@xxxxxxxxx>
Date: Fri, 22 Dec 2006 02:11:48 +0300
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 28 Dec 2006 03:09:59 -0800
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kXW2AGaom7ytceiKsg0kt4R0BTluGwQIKHzuHgqLomgyV3qD4cq6Qyt60x3jPHIkLkF6LtgeVuygdMK/4RHH+R1ujYenXo/0Q32Ks8XNMkzT+4+HzSnZGpu5fufnlB+qskapqSXNah1bnzmyzbJWT9gwEjomoCMlcym7jqxrdaA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061117002945.GA16145@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061115043827.GA23613@xxxxxxxxxxxxxxxxxxx> <20061117002945.GA16145@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 11/17/06, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
On Wed, Nov 15, 2006 at 03:38:27PM +1100, herbert wrote:
>
> CP_TX_BUFFER_SIZE is already 64K.  So it seems to me that we don't need
> the while loop to extend the buffer at all since no transmitted packet
> should be anywhere near this size.
>
> Are there any objections to getting rid of the following while loop
> altogether and replacing it with a straight failure?

Since I haven't heard any objections, here is a patch to do just that.

[QEMU] rtl8139: Disallow chaining above 64K

As it stands the 8139C+ TX chaining is only bounded by realloc failure.
This is contrary to how the real hardware operates.  It also has DoS
potential when ioemu runs in dom0.

This patch makes any attempt to chain a frame beyond 64K fail immediately.

True, a limit would be useful. It may be possible to start a chain at first TX descriptor and keep feeding the card with new buffers while hardware is sending older ones, without underrun, if checksum offloading is disabled. Emulation is assembling a complete packet to feed slirp routine - so there is another limit on packet size, the one slirp is able to handle.

It would be nice to know what is the actual hardware limit for chaining. Only reference to 64K I found in docs is referring to receive ring buffer size in "C" mode.

--
Kind Regards,
Igor V. Kovalenko
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Re: [Qemu-devel] Re: qemu/rtl8139: Max transmit frame size, Igor Kovalenko <=