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

Pravin Shelar pshelar at nicira.com
Wed Sep 3 18:42:18 UTC 2014


On Wed, Sep 3, 2014 at 8:20 AM, John Fastabend <john.fastabend at gmail.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 at resnulli.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_*
>

struct sw_flow_key is internal structure of OVS, it is designed to
have better flow-table performance. By adding hw specific fields in
sw_flow_key, it increase flow-key size and that has negative impact on
OVS software switching performance. Therefore it is better not to
share this internal structure with driver interface.

Thanks.

> 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



More information about the dev mailing list