linux-imx

/*

 * net/sched/cls_rsvp.h Template file for RSVPv[46] classifiers.

 *

 *      This program is free software; you can redistribute it and/or

 *      modify it under the terms of the GNU General Public License

 *      as published by the Free Software Foundation; either version

 *      2 of the License, or (at your option) any later version.

 *

 * Authors: Alexey Kuznetsov, <kuznet@ms2.inr.ac.ru>

 */

​

/*

   Comparing to general packet classification problem,

   RSVP needs only sevaral relatively simple rules:

​

   * (dst, protocol) are always specified,

     so that we are able to hash them.

   * src may be exact, or may be wildcard, so that

     we can keep a hash table plus one wildcard entry.

   * source port (or flow label) is important only if src is given.

​

   IMPLEMENTATION.

​

   We use a two level hash table: The top level is keyed by

   destination address and protocol ID, every bucket contains a list

   of "rsvp sessions", identified by destination address, protocol and

   DPI(="Destination Port ID"): triple (key, mask, offset).

​

   Every bucket has a smaller hash table keyed by source address

   (cf. RSVP flowspec) and one wildcard entry for wildcard reservations.

   Every bucket is again a list of "RSVP flows", selected by

   source address and SPI(="Source Port ID" here rather than

   "security parameter index"): triple (key, mask, offset).

​

​

   NOTE 1. All the packets with IPv6 extension headers (but AH and ESP)

   and all fragmented packets go to the best-effort traffic class.

​

​

   NOTE 2. Two "port id"'s seems to be redundant, rfc2207 requires

   only one "Generalized Port Identifier". So that for classic

   ah, esp (and udp,tcp) both *pi should coincide or one of them

   should be wildcard.

​

   At first sight, this redundancy is just a waste of CPU

   resources. But DPI and SPI add the possibility to assign different

   priorities to GPIs. Look also at note 4 about tunnels below.

​

​

   NOTE 3. One complication is the case of tunneled packets.

   We implement it as following: if the first lookup

   matches a special session with "tunnelhdr" value not zero,

   flowid doesn't contain the true flow ID, but the tunnel ID (1...255).

   In this case, we pull tunnelhdr bytes and restart lookup

   with tunnel ID added to the list of keys. Simple and stupid 8)8)

   It's enough for PIMREG and IPIP.

​

​

   NOTE 4. Two GPIs make it possible to parse even GRE packets.

   F.e. DPI can select ETH_P_IP (and necessary flags to make

   tunnelhdr correct) in GRE protocol field and SPI matches

   GRE key. Is it not nice? 8)8)

​

​

   Well, as result, despite its simplicity, we get a pretty

   powerful classification engine.  */

​

​

struct rsvp_head {

    u32         tmap[256/32];

    u32         hgenerator;

    u8          tgenerator;

    struct rsvp_session __rcu *ht[256];

    struct rcu_head     rcu;

};

​

struct rsvp_session {

    struct rsvp_session __rcu   *next;

    __be32              dst[RSVP_DST_LEN];

    struct tc_rsvp_gpi      dpi;

    u8              protocol;

    u8              tunnelid;

    /* 16 (src,sport) hash slots, and one wildcard source slot */

    struct rsvp_filter __rcu    *ht[16 + 1];

    struct rcu_head         rcu;

};

​

​

struct rsvp_filter {

    struct rsvp_filter __rcu    *next;

    __be32              src[RSVP_DST_LEN];

    struct tc_rsvp_gpi      spi;