[Cake] the evolving skb_flow_dissect functions in linux 4.x?

[Cake] the evolving skb_flow_dissect functions in linux 4.x?

[Dave Taht]

Dear tom and jiri:

I gotta admit that my brain crashed when attempting to understand the logic
and usage of the rework of the flow_dissector.c related code. I am bit
concerned that it is slower than it used to be, also. But....

I started this morning to try to bring the currently out of tree
"cake" qdisc up to date, and

A) The hash is now unconditionally stored in the skb?

Is this sort of a small step towards one day doing all basic hashing
and timestamping on the recv path? (/me says hopefully)

(where is this going, ultimately?)

B) I was wondering as to the proper new api to bring over src and/or
dest only hashing to the new stuff.

The current hashing stuff in cake is here:

https://github.com/dtaht/sch_cake/blob/master/sch_cake.c#L204

for more details on cake (which does 8 way associative hashing also), see:

http://www.bufferbloat.net/projects/codel/wiki/Cake

relevant routine Included inline below but I suspect it would be mangled.

static inline unsigned int
                                  |                        return
true;
cake_fqcd_hash(const struct cake_fqcd_sched_data *q, const struct
sk_buff *skb, int flow_mode)           |                }
{
                                  |
    struct flow_keys keys;
                                  |                break;
    unsigned int hash;
                                  |        }

                                  |        case htons(ETH_P_8021AD):
        if(unlikely(flow_mode == CAKE_FLOW_NONE))
                                  |        case htons(ETH_P_8021Q): {
                return 0;
                                  |                const struct
vlan_hdr *vlan;

                                  |                struct vlan_hdr
_vlan;
    skb_flow_dissect(skb, &keys);
                                  |

                                  |                vlan =
__skb_header_pointer(skb, nhoff, sizeof(_vlan), data, hlen, &_vlan);
        if(flow_mode != CAKE_FLOW_ALL) {
                                  |                if (!vlan)
                keys.ip_proto = 0;
                                  |                        return
false;
                keys.ports = 0;
                                  |

                                  |                proto =
vlan->h_vlan_encapsulated_proto;
                if(!(flow_mode & CAKE_FLOW_SRC_IP))
                                  |                nhoff +=
sizeof(*vlan);
                        keys.src = 0;
                                  |                goto again;

                                  |        }
                if(!(flow_mode & CAKE_FLOW_DST_IP))
                                  |        case htons(ETH_P_PPP_SES):
{
                        keys.dst = 0;
                                  |                struct {
        }
                                  |                        struct
pppoe_hdr hdr;

                                  |                        __be16
proto;
    hash = jhash_3words((__force u32)keys.dst,
                                  |                } *hdr, _hdr;
                (__force u32)keys.src ^ keys.ip_proto,
                                  |                hdr =
__skb_header_pointer(skb, nhoff, sizeof(_hdr), data, hlen, &_hdr);
                (__force u32)keys.ports, q->perturbation);
                                  |                if (!hdr)

                                  |                        return
false;
        return reciprocal_scale(hash, q->flows_cnt);
                                  |                proto = hdr->proto;
}

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Cake] the evolving skb_flow_dissect functions in linux 4.x?

[Jonathan Morton]

> On 22 May, 2015, at 21:36, Dave Taht <dave.taht@gmail.com> wrote:
> 
> B) I was wondering as to the proper new api to bring over src and/or
> dest only hashing to the new stuff.

From my point of view, I would like to see both the complete 5-tuple “flows" hash and individual srchost and dsthost hashes, such that I can XOR the latter two together to get a combined “hosts” hash.  Having those available simultaneously would let me do some very neat things in sch_cake, and potentially other future work too.

 - Jonathan Morton

Re: [Cake] the evolving skb_flow_dissect functions in linux 4.x?

[Dave Taht]

On Sun, May 24, 2015 at 9:51 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 22 May, 2015, at 21:36, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> B) I was wondering as to the proper new api to bring over src and/or
>> dest only hashing to the new stuff.
>
> From my point of view, I would like to see both the complete 5-tuple “flows" hash and individual srchost and dsthost hashes, such that I can XOR the latter two together to get a combined “hosts” hash.  Having those available simultaneously would let me do some very neat things in sch_cake, and potentially other future work too.

I have a working 4.1rc3 version now but it is either without or with
the 5 tuple hash. Still haven't decoded how to use the api.

I would like to also have something that could use a dest mac hash
instead, this would (with an increased quantum) make it possible to
look harder
at per-station queuing (at this layer) for wifi. (still, think we need
to be working at the mac80211 layer for that, but...)

>
>  - Jonathan Morton
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67