[Cake] flow dissection vs encapsulated traffic?
Toke Høiland-Jørgensen
toke at toke.dk
Sun Feb 5 17:17:35 EST 2023
- Previous message (by thread): [Cake] flow dissection vs encapsulated traffic?
- Next message (by thread): [Cake] Fwd: Domos Latency Webinar Series featuring: Apple, Comcast, Vodafone, Nokia, CloudFlare, Ericsson, Ookla, GameBench, Red Hat, Daily, Bufferbloat
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Dave Taht via Cake <cake at lists.bufferbloat.net> writes:
> In looking how the code has morphed since I last looked at it, I found
> myself staring at this bit...
>
> skb_flow_dissect_flow_keys(skb, &keys,
> FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);
>
> // so we have delved deeply into the packet at this point... finding
> various encapsulations...
>
> then we get to:
>
> /* Don't use the SKB hash if we change the lookup keys from conntrack */
> if (nat_enabled && cake_update_flowkeys(&keys, skb))
> use_skbhash = false;
>
> This leverages skb_protocol(), which as best as I can tell just peers
> into the *vlan headers*,
> not deeper into the packet...
>
> Then we proceed merrily into the update_flowkeys code thinking it is
> the outer type
> (ipv4), not the inner, then dissect away, using a v4 union...
>
> Am I reading this wrong? Please tell me I am reading this wrong...
I don't follow. What's the bug you are seeing, specifically?
-Toke
- Previous message (by thread): [Cake] flow dissection vs encapsulated traffic?
- Next message (by thread): [Cake] Fwd: Domos Latency Webinar Series featuring: Apple, Comcast, Vodafone, Nokia, CloudFlare, Ericsson, Ookla, GameBench, Red Hat, Daily, Bufferbloat
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Cake
mailing list