RE: [Xen-devel] RFC: Xen VMDq patch for ixgbe

["Williams, Mitch A" <mitch.a.williams@xxxxxxxxx>]

Whoops!  Attached the wrong patch file.  Please use this one.

Sorry for the confusion.
-Mitch 

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>Mitch Williams
>Sent: Friday, January 16, 2009 3:06 PM
>To: xen-devel@xxxxxxxxxxxxxxxxxxx
>Cc: steven.smith@xxxxxxxxxxxxx; Ronciak, John; joserenato.santos@xxxxxx
>Subject: [Xen-devel] RFC: Xen VMDq patch for ixgbe
>
>Attached is a patch to enable Xen VMDq (AKA Netchannel2 vmq) for the
>ixgbe driver.  This is intended for testing and development purposes
>and should not be considered to be production-quality code.
>
>Please note that this does NOT apply to the Xen Linux kernel; it
>applies to the ixgbe 1.3.47 release, available from
>http://sourceforge.net/projects/e1000/.  You'll obviously also need an
>Intel 82598-based 10 Gigabit network card and some sort of link
>partner.  This will build against the current Netchannel2 source
>available from http:xenbits.xen.org/ext/netchannel2.  You'll need to
>enable "Net channel 2 support for multi-queue devices" in your kernel
>config.
>
>To enable VMDq functionality, load the driver with the command-line
>parameter VMDQ=<num queues>, as in:
>
>$ insmod ~/ixgbe-1.3.47/src/ixgbe.ko VMDQ=8
>
>You can then set up PV domains to use the device by modifying your VM
>configuration file from
>     vif = [ '<whatever>' ]
>to
>     vif2 = [ 'pdev=<netdev>' ]
>where <netdev> is the interface name for your 82598 board, e.g 
>peth0 in dom0.
>
>Known issues (at least, known by me):
>1) Must manually attach bridge device after starting domU vm.
>Netchannel2 backend devices show up as ethNN, not vifN.M, so the
>scripts don't automatically attach the interface.  Once your VM
>starts, do ifconfig -a to see which new interface got added.  Then use
>"brctl addif" to add this new interface the the bridge.
>2) No broadcast replication.  This is a big one.  Incoming broadcasts
>will ONLY go to dom0.  This means that your VMs can send ARP requests
>and initiate IP sessions to outside machines, but outside machines
>cannot initiate connections because the ARP requests don't go to the
>domU VMs.
>3) No loopback.  VMs cannot communicate with other VMs (including
>dom0) on the same machine.
>
>Once I get this out, I'll start working on a proper backport of the
>driver into the Xen kernel (2.6.18.8) tree.  I'll remove as much of
>the compatibility cruft as is prudent and properly integrate it into
>the Kbuild stuff.   When that's done, I'll send a complete patchset to
>this list, including signed-off-by lines which can then be checked in
>to Mercurial.
>
>Please review and comment, and if possible test.
>
>Thanks,
>Mitch
>

Attachment: ixgbe-1.3.47-xen-vmq.diff
Description: ixgbe-1.3.47-xen-vmq.diff

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