From: Dave Taht <dave.taht@gmail.com>
To: tom@herbertland.com, Jiri Pirko <jiri@resnulli.us>,
cake@lists.bufferbloat.net
Subject: [Cake] the evolving skb_flow_dissect functions in linux 4.x?
Date: Fri, 22 May 2015 11:36:02 -0700 [thread overview]
Message-ID: <CAA93jw6Y3H5H4_MVAxTqt2QvdBRQtSRGQEZ5_2T91j+sXKrhRw@mail.gmail.com> (raw)
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
next reply other threads:[~2015-05-22 18:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 18:36 Dave Taht [this message]
2015-05-25 4:51 ` Jonathan Morton
2015-05-25 19:27 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw6Y3H5H4_MVAxTqt2QvdBRQtSRGQEZ5_2T91j+sXKrhRw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=jiri@resnulli.us \
--cc=tom@herbertland.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox