[ovs-dev] [RFC] Making OVS less Ethernet specific

Jesse Gross jesse at nicira.com
Mon Jun 10 22:09:33 UTC 2013


On Wed, Jun 5, 2013 at 2:56 PM, Lori Jakab <lojakab at cisco.com> wrote:
> At a high level, we would introduce layer 3 (tunnel) vports, and LISP
> would be such a vport.  Whenever a packet that ingressed on a L2 vport
> needs to egress on a L3 vport, we apply the internal pop_eth action
> automatically.  For packets going from L3 vports to L2 vports, a
> push_eth action would add a MAC header, with addresses determined by ARP
> resolution in user space.

One other thing that you might want to keep in the back of your mind
as you implement this is how it might interact with MAC-in-MAC
encapsulation. OVS doesn't currently support this but if it did (and
there have been requests), it would presumably want to use these
actions as well.

> One such decision is how to handle the flow key.  I set all fields in
> key->eth to 0, except the type, because we still need to know what kind
> of L3 packet do we have.  Since a lot of code is accessing
> key->eth.type, this is easier than having this information in a
> different place, although it would be more elegant to set this field to
> 0 as well.

Can we use skb->protocol for the cases where we currently access the
EtherType? Are there cases that you are particularly concerned about?

>  Now, in order to differentiate flows with mac addresses set
> to 0 and flows without an Ethernet header, I added a boolean field to
> tun_key, to mark L3 flows.

For internal kernel usage, it might be more convenient to represent
this as a flag in OVS_CB(skb). When we communicate to userspace, we
could indicate that the packet is L3 by simply not including the
Ethernet attribute.

> However, if we expect to have non-tunneled
> L3 ports (I couldn't find a good reason for this) then we should move it
> out into the main flow key structure.

An example that comes to mind for this is L3 internal ports. Probably
this would be mostly for talking to an L3 tunnel port but it is still
a distinct port type, so I think it is good to make L3 ports generic.



More information about the dev mailing list