[ovs-dev] layer 3 ports and OVS_KEY_ATTR_PACKET_ETHERTYPE (was Re: [PATCH v8 5/5] datapath: add layer 3 support to ovs_packet_cmd_execute())

Thomas Morin thomas.morin at orange.com
Tue Jan 20 10:52:08 UTC 2015


Hi Jarno, Lori,

On 12/10/2014 02:45 AM, Jarno Rajahalme wrote:
> We should add a new metadata key field OVS_KEY_ATTR_PACKET_ETHERTYPE, that contains the ethertype of the associated packet attribute. While this would be strictly needed only for L3 packets, it would be cleaner to include it with all packets in packet misses. Then it could be used in flow setup and packet execution as well.
>
> Other packet type namespaces (like IP protocol) could be later supported defining new netlink attributes.
>
> A corresponding new field packet_ethertype needs to be added in struct pkt_metadata. This needs to be kept upto date in userspace code pushing and popping headers, so that the correct value gets passed to kernel execution.

Having the tunneled payload type be passed between kernel and userspace 
via OVS_KEY_ATTR_PACKET_ETHERTYPE is something needed for MPLS/GRE too  
(see [1] below).

With some hints from Jesse back in November, I've been working in the 
past weeks to see how much needed to be adapted based on your patch to 
add support for l3 GRE tunnel ports, and have this work for 
MPLS-over-GRE payloads.  I've not everything covered yet, but I have the 
basic stuff working (with a kernel dataplane).

Here is an outline of the things I did to support MPLS/GRE based on the 
current l3 port patch (l3_v9), and that I think that these are also 
relevant to simplify the code in the IP/non-MPLS case :
- kernel: adapt ovs_nla_put_flow to include 
OVS_KEY_ATTR_PACKET_ETHERTYPE in the noethernet case  (not done in the 
current l3_v9 patch, in which the kernel datapath consume a value given 
by userspace for a flow put or a command execute, but does not provides 
this info on a flow miss)
- user: have odp_key_to_pkt_metadata determine md->packet_ethertype 
based on OVS_KEY_ATTR_PACKET_ETHERTYPE, rather than base on the presence 
of OVS_KEY_ATTR_IPV4 or OVS_KEY_ATTR_IPV6)
- user: similarly for parse_ethertype, to determine the ethertype (based 
on OVS_KEY_ATTR_PACKET_ETHERTYPE rather than base on the presence of 
OVS_KEY_ATTR_IPV4 or OVS_KEY_ATTR_IPV6)
- user: have miniflow_extract rely on md->packet_ethertype for layer3 
frames and do not use get_l3_eth_type anymore (which was guessing 
ethertype based on the version field of the IP header)
- kernel: have ovs_key_from_nlattrs use OVS_KEY_ATTR_PACKET_ETHERTYPE, 
if present,  to determine the ethertype

Comments ?

Lori, I have the above working on my tree and will share code if we 
agree that this is the right direction.

Best,

-Thomas

[1] because MPLS can be used with two ethertypes (0x8847,0x8848) and a 
different semantic can be given to an MPLS label depending on the 
ethtype. This contrasts with IP, for which the ethertype can be 
guessed/derived from the presence of OVS_KEY_ATTR_IPV(4|6) or the 
version field of the IP header.



More information about the dev mailing list