---------- Forwarded message ----------
From: Ajmer Singh <ajmersingh.t...@gmail.com>
Date: Fri, Mar 11, 2016 at 3:16 PM
Subject: Re: [ovs-dev] Where to add GTP tunnel headers in datapath flow
table of open vSwitch
To: Jesse Gross <je...@kernel.org>
Hi,
openflow1.3 specification supports below match fields.
enum oxm_ofb_match_fields {
OFPXMT_OFB_IN_PORT = 0, /* Switch input port. */
OFPXMT_OFB_IN_PHY_PORT = 1, /* Switch physical input port. */
OFPXMT_OFB_METADATA = 2, /* Metadata passed between tables. */
OFPXMT_OFB_ETH_DST = 3, /* Ethernet destination address. */
OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */
OFPXMT_OFB_ETH_TYPE = 5, /* Ethernet frame type. */
OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */
---------------------------------------
OFPXMT_OFB_IPV6_EXTHDR = 39, /* IPv6 Extension Header pseudo-field */
}
but open Vswitch2.4 does have different enum constants for match fields.
enum OVS_PACKED_ENUM mf_field_id{
MFF_DP_HASH,
MFF_RECIRC_ID,
MFF_CONJ_ID,
MFF_TUN_ID,
MFF_TUN_SRC,
MFF_TUN_DST,
MFF_TUN_FLAGS,
MFF_TUN_TTL,
MFF_TUN_TOS,
MFF_TUN_GBP_ID,
MFF_TUN_GBP_FLAGS,
MFF_METADATA,
MFF_IN_PORT,
MFF_IN_PORT_OXM,
MFF_ACTSET_OUTPUT,
MFF_SKB_PRIORITY,
MFF_PKT_MARK,
MFF_REG0,
MFF_REG1,
MFF_REG2,
MFF_REG3,
MFF_REG4,
MFF_REG5,
MFF_REG6,
MFF_REG7,
#error "Need to update MFF_REG* to match FLOW_N_REGS"
MFF_XREG0,
MFF_XREG1,
MFF_XREG2,
MFF_XREG3,
#error "Need to update MFF_REG* to match FLOW_N_XREGS"
MFF_ETH_SRC,
MFF_ETH_DST,
MFF_ETH_TYPE,
MFF_VLAN_TCI,
MFF_DL_VLAN,
MFF_VLAN_VID,
MFF_DL_VLAN_PCP,
MFF_VLAN_PCP,
MFF_MPLS_LABEL,
MFF_MPLS_TC,
MFF_MPLS_BOS,
/* Update mf_is_l3_or_higher() if MFF_IPV4_SRC is no longer the first
element
MFF_IPV4_SRC,
MFF_IPV4_DST,
MFF_IPV6_SRC,
MFF_IPV6_DST,
MFF_IPV6_LABEL,
MFF_IP_PROTO,
MFF_IP_DSCP,
MFF_IP_DSCP_SHIFTED,
MFF_IP_ECN,
MFF_IP_TTL,
MFF_IP_FRAG,
MFF_ARP_OP,
MFF_ARP_SPA,
MFF_ARP_TPA,
MFF_ARP_SHA,
MFF_ARP_THA,
MFF_TCP_SRC,
MFF_TCP_DST,
MFF_TCP_FLAGS,
MFF_UDP_SRC,
MFF_UDP_DST,
MFF_SCTP_SRC,
MFF_SCTP_DST,
MFF_ICMPV4_TYPE,
MFF_ICMPV4_CODE,
MFF_ICMPV6_TYPE,
MFF_ICMPV6_CODE,
MFF_ND_TARGET,
MFF_ND_SLL,
MFF_ND_TLL,
MFF_N_IDS
}
Could you please guide how these maps to standard openflow specification
match fields?
Regards,
Ajmer
On Fri, Mar 11, 2016 at 3:10 PM, Ajmer Singh <ajmersingh.t...@gmail.com>
wrote:
> thanks for your response.
>
> On Wed, Mar 9, 2016 at 10:02 PM, Jesse Gross <je...@kernel.org> wrote:
>
>> On Tue, Mar 8, 2016 at 9:24 PM, Ajmer Singh <ajmersingh.t...@gmail.com>
>> wrote:
>> > I have now question related to mapping of ofp_header->type (OFPT_) with
>> > OFPRAW_contants
>> >
>> > struct ofp_header {
>> > uint8_t version; /* An OpenFlow version number, e.g.
>> OFP10_VERSION.
>> > */
>> > uint8_t type; /* One of the OFPT_ constants. */
>> > ovs_be16 length; /* Length including this ofp_header. */
>> > ovs_be32 xid; /* Transaction id associated with this packet.
>> > Replies use the same id as was in the request to facilitate pairing. */
>> > };
>> > OFP_ASSERT(sizeof(struct ofp_header) == 8);
>> >
>> > ofphdrs_decode(): openVswitch/lib/ofp-msg.c
>> > this function assumes that openflow header type contains only below enum
>> > constants. My query is why it is not taking care of lot many openflow
>> > messages (PACKET_OUT, FLOW_MOD etc..). your response is much
>> appreciated.
>> > OFPT_VENDOR
>> > OFPT10_STATS_REQUEST
>> > OFPT10_STATS_REPLY
>> > OFPT11_STATS_REQUEST
>> > OFPT11_STATS_REQUEST
>>
>> The comment above struct ofphdrs describes what information is contained
>> in it:
>>
>> /* A thin abstraction of OpenFlow headers:
>> *
>> * - 'version' and 'type' come straight from struct ofp_header, so
>> these are
>> * always present and meaningful.
>> *
>> * - 'stat' comes from the 'type' member in statistics messages only.
>> It is
>> * meaningful, therefore, only if 'version' and 'type' taken together
>> * specify a statistics request or reply. Otherwise it is 0.
>> *
>> * - 'vendor' is meaningful only for vendor messages, that is, if
>> 'version'
>> * and 'type' specify a vendor message or if 'version' and 'type'
>> specify
>> * a statistics message and 'stat' specifies a vendor statistic type.
>> * Otherwise it is 0.
>> *
>> * - 'subtype' is meaningful only for vendor messages and otherwise 0.
>> It
>> * specifies a vendor-defined subtype. There is no standard format
>> for
>> * these but 32 bits seems like it should be enough. */
>>
>> It is not handling any message types, just extracting this
>> information. However, none of this needs to be modified to add a new
>> tunnel type.
>>
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
