Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Jun 2013 16:27:07 -0400
From:      Adam McDougall <mcdouga9@egr.msu.edu>
To:        Colin Percival <cperciva@freebsd.org>
Cc:        freebsd-xen@FreeBSD.org
Subject:   Re: svn commit: r251297 - head/sys/dev/xen/netfront
Message-ID:  <20130607202707.GB4240@egr.msu.edu>
In-Reply-To: <51AD0571.90007@freebsd.org>
References:  <201306031300.r53D0XUx092178@svn.freebsd.org> <51AD0571.90007@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 03, 2013 at 02:06:57PM -0700, Colin Percival wrote:

  On 06/03/13 06:00, Andre Oppermann wrote:
  > Log:
  >   Specify a maximum TSO length limiting the segment chain to what the
  >   Xen host side can handle after defragmentation.
  >   
  >   This prevents the driver from throwing away too long TSO chains and
  >   improves the performance on Amazon AWS instances with 10GigE virtual
  >   interfaces to the normally expected throughput.
  
  Thanks!
  
  For the benefit of the list: This (and the r251296, which provides the
  network stack infrastructure which this commit uses) was the last of the
  "make FreeBSD behave well in Amazon EC2" patches I've been carrying around
  (and building into my EC2 images) for the past two years.
  
  Now the only step remaining to make FreeBSD/EC2 pure "straight off the
  RELEASE ISO" FreeBSD is to get Xen HVM functionality into GENERIC.
  
  -- 
  Colin Percival
  Security Officer Emeritus, FreeBSD | The power to serve
  Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
  
Is it possible to turn it into a boot time tunable in case XENHVM puts
a system at a disadvantage?  I'm specifically thinking of some XENHVM environments
under XenServer and related products that aren't currently compat with having
a virtual cdrom due to a bug.  Removing the virtual cdrom drive is a workaround
but that makes it a lot harder to boot from a RELEASE ISO :)

Apologies if it already has a tunable, but I did some searching and could not
locate it.  It was desirable too back when a XENHVM kernel would panic on bare hw
but that was fixed a while ago.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130607202707.GB4240>