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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
