netdev - Re: [PATCH v2.35 5/6] lib: Push MPLS tags in the OpenFlow 1.3 ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 7 Aug 2013 09:17:40 -0700
From:	Ben Pfaff <blp@...ira.com>
To:	Joe Stringer <joe@...d.net.nz>
Cc:	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	netdev@...r.kernel.org, Ravi K <rkerur@...il.com>,
	Isaku Yamahata <yamahata@...inux.co.jp>,
	Jesse Gross <jesse@...ira.com>,
	Pravin B Shelar <pshelar@...ira.com>,
	jarno.rajahalme@....com, Simon Horman <horms@...ge.net.au>
Subject: Re: [PATCH v2.35 5/6] lib: Push MPLS tags in the OpenFlow 1.3
 ordering

On Tue, Aug 06, 2013 at 11:04:31AM +0900, Joe Stringer wrote:
> The general background to this patch is that we aim to keep the datapath
> interface for MPLS actions simple. As such, when pushing an MPLS tag, this
> is done immediately after the ethernet header regardless of the presence of
> VLANs (As per OF1.3 spec). We can then implement OF1.2 behaviour by popping
> any existing VLAN tags before applying MPLS actions, then pushing the tags
> back on afterwards. This is all done on the odp actions translation side.

I think that keeping the interface simple is a good approach.  Always
pushing labels just after the Ethernet header sounds reasonable to me.
(I don't speak for Jesse.  He might have a different idea.)

> I'm wondering if this general approach is the preferred method, and as an
> extension, what are your thoughts on how these patches add the new
> 'vlan_tci' field into 'struct xlate_in' and apply VLAN actions twice
> (before and/or after MPLS actions). This provides a mechanism to support
> both OF1.2 and OF1.3 behaviours within the scope of current VLAN support,
> but may or may not fit in well with future ideas for QinQ (ie,
> double-stacked 0x8100 tags) or 802.1ad support.

In general, if userspace code works for our current needs, and kernel
code works for our current needs and can be extended to foreseeable
future needs, then that's fine.  I often find it to be a mistake to try
to generalize too much in advance.

Thanks,

Ben.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html