netdev - Re: [patch net-next 01/13] openvswitch: split flow structures into ovs specific and generic ones

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <540731B9.4010603@gmail.com>
Date:	Wed, 03 Sep 2014 08:20:25 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
CC:	netdev@...r.kernel.org, davem@...emloft.net, nhorman@...driver.com,
	andy@...yhouse.net, tgraf@...g.ch, dborkman@...hat.com,
	ogerlitz@...lanox.com, jesse@...ira.com, pshelar@...ira.com,
	azhou@...ira.com, ben@...adent.org.uk, stephen@...workplumber.org,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	xiyou.wangcong@...il.com, john.r.fastabend@...el.com,
	edumazet@...gle.com, jhs@...atatu.com, sfeldma@...ulusnetworks.com,
	f.fainelli@...il.com, roopa@...ulusnetworks.com,
	linville@...driver.com, dev@...nvswitch.org, jasowang@...hat.com,
	ebiederm@...ssion.com, nicolas.dichtel@...nd.com,
	ryazanov.s.a@...il.com, buytenh@...tstofly.org,
	aviadr@...lanox.com, nbd@...nwrt.org, alexei.starovoitov@...il.com,
	Neil.Jerram@...aswitch.com, ronye@...lanox.com
Subject: Re: [patch net-next 01/13] openvswitch: split flow structures into
 ovs specific and generic ones

On 09/03/2014 02:24 AM, Jiri Pirko wrote:
> After this, flow related structures can be used in other code.
>
> Signed-off-by: Jiri Pirko <jiri@...nulli.us>
> ---

Hi Jiri,

As I indicated before I'm looking into integrating this with some
hardware here. Progress is a bit slow but starting to look at it.The
i40e/ixgbe driver being one open source example with very limited
support for tables, flow matches, etc. And then a closed source driver
with much more flexibility. What I don't have is a middle of the road
switch to work with something better then a host nic but not as
flexible as a TOR.

Couple questions my assumption here is I can extend the flow_key
as needed to support additional match criteria my hardware has.
I scanned the ./net/openvswitch source and I didn't catch any
place that would break but might need to take a closer look.
Similarly the actions set will need to be extended. For example
if I want to use this with i40e a OVS_ACTION_ATTR_QUEUE could
be used to steer packets to the queue. With this in mind we
will want a follow up patch to rename OVS_ACTION_ATTR_* to
FLOW_ACTION_ATTR_*

Also I have some filters that can match on offset/length/mask
tuples. As far as I can tell this is going to have to be yet
another interface? Or would it be worth the effort to define
the flow key more generically. My initial guess is I'll just
write a separate interface. I think this is what Jamal referred
to as another "classifier".

Thanks,
John

[...]

> +
> +struct sw_flow_key_ipv4_tunnel {
> +	__be64 tun_id;
> +	__be32 ipv4_src;
> +	__be32 ipv4_dst;
> +	__be16 tun_flags;
> +	u8   ipv4_tos;
> +	u8   ipv4_ttl;
> +};
> +
> +struct sw_flow_key {
> +	struct sw_flow_key_ipv4_tunnel tun_key;  /* Encapsulating tunnel key. */
> +	struct {
> +		u32	priority;	/* Packet QoS priority. */
> +		u32	skb_mark;	/* SKB mark. */
> +		u16	in_port;	/* Input switch port (or DP_MAX_PORTS). */
> +	} __packed phy; /* Safe when right after 'tun_key'. */
> +	struct {
> +		u8     src[ETH_ALEN];	/* Ethernet source address. */
> +		u8     dst[ETH_ALEN];	/* Ethernet destination address. */
> +		__be16 tci;		/* 0 if no VLAN, VLAN_TAG_PRESENT set otherwise. */
> +		__be16 type;		/* Ethernet frame type. */
> +	} eth;
> +	struct {
> +		u8     proto;		/* IP protocol or lower 8 bits of ARP opcode. */
> +		u8     tos;		/* IP ToS. */
> +		u8     ttl;		/* IP TTL/hop limit. */
> +		u8     frag;		/* One of OVS_FRAG_TYPE_*. */
> +	} ip;
> +	struct {
> +		__be16 src;		/* TCP/UDP/SCTP source port. */
> +		__be16 dst;		/* TCP/UDP/SCTP destination port. */
> +		__be16 flags;		/* TCP flags. */
> +	} tp;
> +	union {
> +		struct {
> +			struct {
> +				__be32 src;	/* IP source address. */
> +				__be32 dst;	/* IP destination address. */
> +			} addr;
> +			struct {
> +				u8 sha[ETH_ALEN];	/* ARP source hardware address. */
> +				u8 tha[ETH_ALEN];	/* ARP target hardware address. */
> +			} arp;
> +		} ipv4;
> +		struct {
> +			struct {
> +				struct in6_addr src;	/* IPv6 source address. */
> +				struct in6_addr dst;	/* IPv6 destination address. */
> +			} addr;
> +			__be32 label;			/* IPv6 flow label. */
> +			struct {
> +				struct in6_addr target;	/* ND target address. */
> +				u8 sll[ETH_ALEN];	/* ND source link layer address. */
> +				u8 tll[ETH_ALEN];	/* ND target link layer address. */
> +			} nd;
> +		} ipv6;
> +	};
> +} __aligned(BITS_PER_LONG/8); /* Ensure that we can do comparisons as longs. */
> +
> +struct sw_flow_key_range {
> +	unsigned short int start;
> +	unsigned short int end;
> +};
> +
> +struct sw_flow_mask {
> +	struct sw_flow_key_range range;
> +	struct sw_flow_key key;
> +};
> +
> +struct sw_flow_action {
> +};
> +
> +struct sw_flow_actions {
> +	unsigned count;
> +	struct sw_flow_action actions[0];
> +};
> +
> +struct sw_flow {
> +	struct sw_flow_key key;
> +	struct sw_flow_key unmasked_key;
> +	struct sw_flow_mask *mask;
> +	struct sw_flow_actions *actions;
> +};
> +


-- 
John Fastabend         Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html