| 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
| ||
|
Message-ID: <20140904120907.GD1867@nanopsycho.lan>
Date: Thu, 4 Sep 2014 14:09:07 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: John Fastabend <john.fastabend@...il.com>
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
Wed, Sep 03, 2014 at 05:20:25PM CEST, john.fastabend@...il.com wrote:
>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".
I'm thinking about using some more generic match key. It would
incorporate ovs key and possible other classifiers (as your
off/len/mask) as well. Drivers will have free will to implement whatever
the hw supports.
Will do it for the next version of the patchset (most probably after I
return from holliday, Sep 15).
>
>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
Powered by blists - more mailing lists