Thread (1 message) 1 message, 1 author, 2013-08-07

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

From: Ben Pfaff <hidden>
Date: 2013-08-07 16:17:40

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help