From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 13FE82022C0 for ; Fri, 22 May 2015 11:36:15 -0700 (PDT) Received: by obfe9 with SMTP id e9so19185545obf.1 for ; Fri, 22 May 2015 11:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=AIjnY+IBZoHn4vZDsT+nTol7FmYp3M4bYgDrviYBJ1Q=; b=nL6+7pEeTFw/3yylGI4bXDlplsTNih3OTSWUCln7DOw/w6CwYhe7fV0XZuiCz9Ju5Z cLUzi1GNm2+b4DRLmt9filMyNrA1JY8tM0lTBniCWLPvVgiy+NYiC2CPFEZ7qxC1bUq4 SILu+wM481CZVH6GIP+o8m3RRFC9xv/7MI0F0nQZJ02qc+Cmt2Y5NZSqpsagEndGaLiM lWCVAQ8pH8935PYtZeTVSha6JoTx33R7juJ95y5iVC4xCo3t16Tf6OWAGbUduTVX4dRx Y5Bo9nxuJMZxqO9WXck2z+rdGIi5/Gw4Nf2SmNSN2yuASC7K8V7YOixtHYatt8OVJrcU FT5A== MIME-Version: 1.0 X-Received: by 10.202.216.138 with SMTP id p132mr7297735oig.133.1432319762837; Fri, 22 May 2015 11:36:02 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Fri, 22 May 2015 11:36:02 -0700 (PDT) Date: Fri, 22 May 2015 11:36:02 -0700 Message-ID: From: Dave Taht To: tom@herbertland.com, Jiri Pirko , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] the evolving skb_flow_dissect functions in linux 4.x? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 18:36:51 -0000 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 =3D=3D 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 =3D __skb_header_pointer(skb, nhoff, sizeof(_vlan), data, hlen, &_vlan); if(flow_mode !=3D CAKE_FLOW_ALL) { | if (!vlan) keys.ip_proto =3D 0; | return false; keys.ports =3D 0; | | proto =3D vlan->h_vlan_encapsulated_proto; if(!(flow_mode & CAKE_FLOW_SRC_IP)) | nhoff +=3D sizeof(*vlan); keys.src =3D 0; | goto again; | } if(!(flow_mode & CAKE_FLOW_DST_IP)) | case htons(ETH_P_PPP_SES): { keys.dst =3D 0; | struct { } | struct pppoe_hdr hdr; | __be16 proto; hash =3D jhash_3words((__force u32)keys.dst, | } *hdr, _hdr; (__force u32)keys.src ^ keys.ip_proto, | hdr =3D __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 =3D hdr->proto; } --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67