Has anyone seen performance issues with xen 4.1.0 (the one used in xencenter 6.0) using open vswitch as opposed to native linux bridge ? We are tussling with needing the support guest vlan tagging and performance. Guest VM vlan tagging works with open vswitch . Perf seems to be much better with native linux bridge. Any useful pointers will be very helpul. Thanks, -kvc _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander <vijay.chander@gmail.com>wrote:> Has anyone seen performance issues with xen 4.1.0 (the one used in > xencenter 6.0) > using open vswitch as opposed to native linux bridge ? > > We are tussling with needing the support guest vlan tagging and > performance. > > Guest VM vlan tagging works with open vswitch . Perf seems to be much > better > with native linux bridge. > > Any useful pointers will be very helpul. > > Thanks, > -kvc >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Vijay Chander <vijay.chander@gmail.com> writes:> On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander <vijay.chander@gmail.com> > wrote: > > Has anyone seen performance issues with xen 4.1.0 (the one used in > xencenter 6.0) > using open vswitch as opposed to native linux bridge ? > > We are tussling with needing the support guest vlan tagging and > performance.XenServer 6.0.0 shipped with an Open vSwitch build that contained a serious VLAN performance bug. It is fixed on the Open vSwitch "vlan-maint" branch. The fix should also appear in the next XenServer release. Here is the Open vSwitch commit that fixed the problem. --8<--------------------------cut here-------------------------->8-- From: Ben Pfaff <blp@nicira.com> Date: Wed, 23 Mar 2011 10:34:37 -0700 Subject: [PATCH] datapath: Add compatibility with sk_buff's vlan_tci before 2.6.33. Between 2.6.27 and 2.6.32, the vlan_tci member of struct sk_buff was the raw value of the 802.1Q header's TCI field, without the CFI bit being set. In 2.6.33 and later, the CFI bit is always set if an 802.1Q header is present, correcting a corner case. Until now, OVS has not consistently dealt with this. If a packet arrived at a datapath from a network device directly, or if it was set with an ODP_ACTION_ATTR_SET_DL_TCI action, then the CFI bit would not be set in vlan_tci. In flow_extract(), OVS copies vlan_tci directly to dl_tci in the flow structure (via vlan_get_tci()), so the CFI bit would also not be set in dl_tci. But if OVS had to send a packet up to userspace (converting the vlan_tci back to an 802.1Q header along the way) and got it back, then it would set the VLAN CFI bit in dl_tci when it parsed the 802.1Q header in parse_vlan(). This had the effect that a flow set up by userspace (with the CFI bit set) would never be matched by a packet arriving from a network device, because they would have different dl_tci values. This fixes the problem, by making the vlan_get_tci() and vlan_set_tci() interface consistent across kernel versions. Now, they always accept or return a value where the VLAN CFI bit is set if an 802.1Q header is present. Build-tested only. Problem isolated by Ethan Jackson <ethan@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com> Reported-by: Ram Jothikumar <rjothikumar@nicira.com> Bug #4915. --- datapath/vlan.h | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/datapath/vlan.h b/datapath/vlan.h index 02a6290..7e1084e 100644 --- a/datapath/vlan.h +++ b/datapath/vlan.h @@ -13,6 +13,29 @@ #include <linux/skbuff.h> #include <linux/version.h> +/** + * DOC: VLAN tag manipulation. + * + * &struct sk_buff handling of VLAN tags has evolved over time: + * + * In 2.6.26 and earlier, VLAN tags did not have any generic representation in + * an skb, other than as a raw 802.1Q header inside the packet data. + * + * In 2.6.27 &struct sk_buff added a @vlan_tci member. Between 2.6.27 and + * 2.6.32, its value was the raw contents of the 802.1Q TCI field, or zero if + * no 802.1Q header was present. This worked OK except for the corner case of + * an 802.1Q header with an all-0-bits TCI, which could not be represented. + * + * In 2.6.33, @vlan_tci semantics changed. Now, if an 802.1Q header is + * present, then the VLAN_TAG_PRESENT bit is always set. This fixes the + * all-0-bits TCI corner case. + * + * For compatibility we emulate the 2.6.33+ behavior on earlier kernel + * versions. The client must not access @vlan_tci directly. Instead, use + * vlan_get_tci() to read it or vlan_set_tci() to write it, with semantics + * equivalent to those on 2.6.33+. + */ + #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27) #define NEED_VLAN_FIELD #endif @@ -22,11 +45,18 @@ static inline void vlan_copy_skb_tci(struct sk_buff *skb) { } static inline u16 vlan_get_tci(struct sk_buff *skb) { +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) + if (skb->vlan_tci) + return skb->vlan_tci | VLAN_TAG_PRESENT; +#endif return skb->vlan_tci; } static inline void vlan_set_tci(struct sk_buff *skb, u16 vlan_tci) { +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) + vlan_tci &= ~VLAN_TAG_PRESENT; +#endif skb->vlan_tci = vlan_tci; } #else -- 1.7.2.5 -- Ben Pfaff http://benpfaff.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I saw similar issue being described on citrix official forum. Some guy compiled by own version 1.3 of open vswitch and problems dissapeared. This problem should be fixed in XenServer 6.0 SP1 but release date is not know yet. Br Peter 2012/1/19 Vijay Chander <vijay.chander@gmail.com>:> Has anyone seen performance issues with xen 4.1.0 (the one used in xencenter > 6.0) > using open vswitch as opposed to native linux bridge ? > > We are tussling with needing the support guest vlan tagging and performance. > > Guest VM vlan tagging works with open vswitch . Perf seems to be much better > with native linux bridge. > > Any useful pointers will be very helpul. > > Thanks, > -kvc > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users
On Thu, 2012-01-19 at 05:15 +0000, Vijay Chander wrote:> > > On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander > <vijay.chander@gmail.com> wrote: > Has anyone seen performance issues with xen 4.1.0 (the one > used in xencenter 6.0)Issues with XenServer should be reported either to XenServer support or via the appropriate forum on forums.citrix.com. Thanks. Ian.
On 19/01/12 14:00, Ian Campbell wrote:> On Thu, 2012-01-19 at 05:15 +0000, Vijay Chander wrote: >> >> On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander >> <vijay.chander@gmail.com> wrote: >> Has anyone seen performance issues with xen 4.1.0 (the one >> used in xencenter 6.0) > Issues with XenServer should be reported either to XenServer support or > via the appropriate forum on forums.citrix.com. > > Thanks. > Ian.However, in the interest of fixing your problem. A Hotfix for this issue has already been released. Please google for it - it is not hard to find.> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
Citrix has released a patch for XS 6.0 to address some of the issues with the openvswitch as well: http://support.citrix.com/article/CTX131745 -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Peter Braun Sent: Thursday, January 19, 2012 2:59 AM To: Xen List Subject: Re: [Xen-users] xen + openvswitch I saw similar issue being described on citrix official forum. Some guy compiled by own version 1.3 of open vswitch and problems dissapeared. This problem should be fixed in XenServer 6.0 SP1 but release date is not know yet. Br Peter 2012/1/19 Vijay Chander <vijay.chander@gmail.com>:> Has anyone seen performance issues with xen 4.1.0 (the one used in > xencenter > 6.0) > using open vswitch as opposed to native linux bridge ? > > We are tussling with needing the support guest vlan tagging and performance. > > Guest VM vlan tagging works with open vswitch . Perf seems to be much > better with native linux bridge. > > Any useful pointers will be very helpul. > > Thanks, > -kvc > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users