qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH v4] rtl8139: add vlan support


From: Benjamin Poirier
Subject: [Qemu-devel] [PATCH v4] rtl8139: add vlan support
Date: Wed, 2 Mar 2011 17:36:18 -0500

I've tested v4 with x86_64 host/guest. I used the same testing procedure as
before. I've tested a plain configuration as well as one with tso + vlan
offload, successfully.

I had to hack around the Linux 8139cp driver to be able to enable tso on vlan
which leads me to wonder, can someone with access to the C+ spec or a real
card confirm that it can do tso and vlan offload at the same time? The patch
I used for the kernel is at https://gist.github.com/851895.

Changes since v2:
insertion:
        * moved insertion later in the process, to handle tso
        * use qemu_sendv_packet() to insert the tag for us
        * added dot1q_buf parameter to rtl8139_do_receive() to avoid some
          memcpy() in loopback mode. Note that the code path through that
          function is unchanged when dot1q_buf is NULL.

extraction:
        * reduced the amount of copying by moving the "frame too short" logic
          after the removal of the vlan tag (as is done in e1000.c for
          example). Unfortunately, that logic can no longer be shared betwen
          C+ and C mode.

I've posted v2 of these patches back in November
http://article.gmane.org/gmane.comp.emulators.qemu/84252

I've tested v3 on the following combinations of guest and hosts:
host: x86_64, guest: x86_64
host: x86_64, guest: ppc32
host: ppc32, guest: ppc32

Testing on the x86_64 host used '-net tap' and consisted of:
* making an http transfert on the untagged interface.
* ping -s 0-1472 to another host on a vlan.
* making an scp upload to another host on a vlan.

Testing on the ppc32 host used '-net socket' connected to an x86_64 qemu-kvm
running the virtio nic and consisted of:
* establishing an ssh connection between the two using an untagged interface.
* ping -s 0-1472 between the two using a vlan.
* making an scp transfer in both directions using a vlan.

All that was successful. Nevertheless, it doesn't exercise all code paths so
care is in order.

Please note that the lack of vlan support in rtl8139 has taken a few people
aback:
https://bugzilla.redhat.com/show_bug.cgi?id=516587
http://article.gmane.org/gmane.linux.network.general/14266

Thanks,
-Ben



reply via email to

[Prev in Thread] Current Thread [Next in Thread]